# monitor

**Repository Path**: godY/monitor

## Basic Information

- **Project Name**: monitor
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 1
- **Forks**: 0
- **Created**: 2020-06-12
- **Last Updated**: 2020-12-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# Monitor介绍

## 背景

当前环境有很多app服务在运行，每个app都有自己的日记记录文件。

## 目的

监控某个app服务的日志，实时的统计分析日志，计算出QPS，接口访问数量、流量、运行状态、等相关数据，以图形的方式展示出来。

## 途径

日志是作为唯一的接入点，被监控的app不需要主动上报，被动的由agent来收集日志。

## 非侵入性

服务的统计信息，往往都需要改动源代码或者嵌入某些统计包埋点的方式来实现，对于新的业务新的代码，可以采用嵌入是的方案来实现。

但是很多线上的代码比较老旧(很难维护，也没人愿意修改)，则可以通过实时监控日志的方式，监控服务的运行状态。

如果没有相对完备的日志，增加一个日志记录，或者修改日志记录，相比修改业务逻辑(主动上报模式)，影响较小。


## Agent和Svr介绍

采用agent和svr分离模式，agent和svr完全解耦，通过broker连接在一起，agent和svr不需要知道对方的存在形式，也不完全需要知道具体的实现方案。

agent负责收集消息

svr负责处理消息

监控对象是app service，某个服务，不是针对某一个日志

一个app service下面可以有多个日志，这个属于内部细节问题，不需要暴露在外部，如果要停用某个日志的监控，也属于app内部问题

# 通讯

通讯采用pub/sub模式，同时也有request模式

通讯协议是json

# 部署模式

agent和svr采用1：N模式。即1个agent可以对应N个svr。

比如有Aservice(简称A)需要接入监控,

A部署了3分A1,A2,A3，

方案1:

每一个A对应一个agent，每一个agent对应3个svr

1. A1-agent
1. A2-agent
1. A3-agent
1. A1-svr,A1-svr,A1-svr
1. A2-svr,A2-svr,A2-svr
1. A3-svr,A3-svr,A3-svr