80-starnet-dev.rst.txt
11.4 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
.. role:: raw-html(raw)
:format: html
.. default-role:: raw-html
**********************************
watchmen在繁星的应用与开发
**********************************
20181128整理需求以及设计
===============================
原始需求以及应对方案
------------------------------
::
一.视频点播问题：点播不出来、点播耗时长 、点播的视频质量差等
1.原始流点播：包括平台点播和分析节点点播；原始流类型有国标、相机rtsp、上传视频rtsp
1.原始流点播的信令交互请求、响应日志
2.原始流点播各个环节消耗时长。
3.原始流点播各个环节视频数据质量(码率、帧率、视频数据完整性)
4.视频流服务要转发视频数据，需要监测转发的视频数据路数、负载（CPU、内存、带宽）
2.分析流点播:平台点播分析流，分析流点播基础是分析节点能请求到原始流正常分析输出
1.分析流点播请求、响应日志
2.分析流点播拼串中运维和分析的交互日志----这个环境失败率高**
3.分析流输出视频质量
- 1.1 `<S>sip的所有模块，所有信令均写日志。 转发模块第一帧来了写一条点播成功的日志，调用vproc写状态</S>` ------信令先加错误日志，点播成功日志待定
- 1.2 `<S>转发模块接收到点播指令时记日志。 转发模块第一帧往rtspserver发时加日志。 耗时从日志时间戳计算。</S>` ------点播日志待定
- 1.3 MediaServer利用动态item机制，建立一个点播表。 见**相机状态**表章节
- 1.4 已实现
- 2.1 `<S>rtspserver接收到点播请求写日志。 VAServer接收到点播请求写日志。发出第一帧写日志。</S>` ------先不加，用输出的状态值排查问题
- 2.2 见**会话日志**章节
- 2.3 已有帧率
::
二、平台程序占用资源情况监测：平台程序基于java使用docker容器运行；繁星数据量大，数据读写存储并发高非常消耗资源，当消耗资源过高，会产生很多莫名其妙的异常。
1.监测平台各个docker程序消耗系统资源情况（CPU、内存、IO、带宽等）----以便后续优化
2.监测平台服务器磁盘容量，低于某个阈值报警---避免由于磁盘被占满导致的问题
3.平台程序连接状态监测，例如平台各个服务之间连接监测：配置服务、管理服务、数据库等间的连接状态；平台各个服务与外部各个服务的连接监测：配置服务、管理服务、数据库与运维服务、
4.数据转发服务的连接等
- 1 已配好，见监控docker章节
- 2 已有
- 3/4 见**链路状态**章节
::
三、任务下发、配置、管理环节问题：存在下发任务未运行（下发失败）、配置截图截不到，参数修改不生效、任务删除删除不掉资源无法释放等问题
1.任务下发、删除各个环节请求，响应日志
2.任务下发、删除响应时间（特别大批量下发任务时）
3.任务、节点对应关系（通过节点能直观的知道任务运行在哪个节点）
4.任务配置截图请求、响应日志，消耗时长、图片数据大小等---------截图失败率高**
- 1/2/4. 各服务要增加关键流程的消息日志。 增加统一的TAG（tag_addtask/tag_deletetask等），带消息id，耗时统计。 搜索日志时根据TAG和消息ID了解各环节处理情况。 见**会话日志**章节
- 3 见**任务状态**表章节
::
四、数据接入和转出、数据存储、数据显示问题：任务请求不到数据（视频数据、图片数据）、请求到数据发送失败、发送环节成功但存储失败或丢失等都会导致最终的数据展示
1.数据接入环节需要有请求数据成功和失败的记录，失败报警、数据量记录（如图片数量），数据来源
2.数据转发环节需要有发送成功失败的记录，失败报警，数据量记录，数据来源（关联任务、节点）
3.数据存储环节需要有接收到和存储到数据的成功失败记录，数据量，数据来源（关联任务、节点）
- 4 链路状态 配合 错误日志--所有会导致结果扔掉的日志
会话日志
------------------------------
一个事件，主要是用户操作，整个业务链路的通讯、处理过程均当做一个会话。 经过的所有服务的处理过程均应该增加日志，日志中增加能够描述这个会话的TAG和id。 当发现操作没有达到预期，在elk web中以TAG或id作为搜索条件，查看处理流程中哪个环节的日志有异常。达到快速定位问题的目的。
TAG作为一种会话的类型，可作为第一层筛选。id作为补充，每种流程不同。比如task相关的就用taskid。
会话日志规范（以下日志均需要增加TAG，有条件的还要加id）：
- message输入要将原消息写日志，源头ip。
- 处理过后新的message输出写日志， 目标ip
- 非常关键的处理环节写日志
- 错误写日志，加_ERROR_关键字(头尾加下划线)
在这里罗列一些TAG，方便我们在elk中精准的搜索到想要的日志。持续增加
+-------------------+------------+---------------------------+
| TAG值 | 其他关键字 | 说明 |
+===================+============+===========================+
| tag_add_task | taskid | 添加任务 |
+-------------------+------------+---------------------------+
| tag_del_task | taskid | 删除任务 |
+-------------------+------------+---------------------------+
| tag_edit_task | taskid | 编辑任务 |
+-------------------+------------+---------------------------+
| tag_capture_image | | 截图 |
+-------------------+------------+---------------------------+
| tag_upgrade | | 升级 |
+-------------------+------------+---------------------------+
| tag_playvideo | | 视频点播相关 |
+-------------------+------------+---------------------------+
| tag_result | refid,ip | 结果相关,错误日志必须写。 |
+-------------------+------------+---------------------------+
| tag_playurl | | 点播串相关，取串拼串 |
+-------------------+------------+---------------------------+
请将无用日志删掉，或体量大，平时用不到又不能删的日志，单独写一个文件并告诉我文件名。收集日志时会将其去掉。
相机状态
------------------------------
VAServer的相机状态表已添加。
MediaServer需在内存中维护一个相机状态表，程序增加统计代码， 状态表中保存各统计指标，每隔10秒写使用vproc写状态。
zabbix web增加lld，key: mediaserver.cameras
在此lld内增加items:
如果是sip，[id]写相机编号，rtsp方式[id]写rtsp串（需要把句号.全部去掉）。
+-----------------------------------+--------------------------------------+
| key | 说明 |
+===================================+======================================+
| mediaserver.cameras.[id].playurl | 点播地址 |
+-----------------------------------+--------------------------------------+
| mediaserver.cameras.[id].fps | 接收频率 |
+-----------------------------------+--------------------------------------+
| mediaserver.cameras.[id].bitrate | 码率 |
+-----------------------------------+--------------------------------------+
| mediaserver.cameras.[id].lossrate | 丢包率。 希望rtspclient能检测丢包率 |
+-----------------------------------+--------------------------------------+
| mediaserver.cameras.[id].sendtoip | 字符串，转发目的地ip，多个用逗号隔开 |
+-----------------------------------+--------------------------------------+
链路状态
------------------------------
利用动态item功能，每个服务将自己比较关键的连接写状态。[id]自己定义，每个连接要有唯一性，最好有一定的描述性，比如connect_to_ops, from_vaserver_1。 connect.server是作为服务端，监听到的链接链路。
+--------------------------------------------+----------------------------------------------------+
| key | 描述 |
+============================================+====================================================+
| appname.connection.server.[id].ip | 连接到自己的ip |
+--------------------------------------------+----------------------------------------------------+
| appname.connection.server.[id].status | 长连接时表示连接状态，短连接无意义 |
+--------------------------------------------+----------------------------------------------------+
| appname.connection.server.[id].lastmsgtime | 最后一条消息的时间 |
+--------------------------------------------+----------------------------------------------------+
| appname.connection.client.[id].url | 自己主动连接的地址 |
+--------------------------------------------+----------------------------------------------------+
| appname.connection.client.[id].status | 长连接时表示连接状态，短连接时表示是否能成功发消息 |
+--------------------------------------------+----------------------------------------------------+
| appname.connection.client.[id].lastmsgtime | 最后一条消息的时间 |
+--------------------------------------------+----------------------------------------------------+
**长连接暂时用写脚本调用netstat的方式实现，短连接需要服务在程序内添加。后续发现无法用脚本实现的再通知程序开发者**
任务状态
------------------------------
服务器运维维护一个任务表，任务状态有变化时用vproc写状态
zabbix web增加lld动态item, key: ops.tasks
在此lld内增加items:
+-----------------------+----------------------------+
| key | 说明 |
+=======================+============================+
| ops.tasks.[id].name | 任务名 |
+-----------------------+----------------------------+
| ops.tasks.[id].sendto | 分配到了哪台设备，最好写ip |
+-----------------------+----------------------------+
| ops.tasks.[id].status | 任务状态 |
+-----------------------+----------------------------+
总结各服务需要做的事情
----------------------
sip
^^^^^^^^^^^^
- 错误的信令日志
- 会话日志
MediaServer
^^^^^^^^^^^^^^^^^^^^
- 相机状态表
VAServer
^^^^^^^^^^^^
- 会话日志
DataExportService
^^^^^^^^^^^^^^^^^^^^^^^
- 往平台发消息的链路状态
- 会话日志
平台
^^^^^^^^^^^^
- 所有重要链路状态
- 会话日志
OperateServer
^^^^^^^^^^^^^^^^^^^^^^
- 任务状态表
- 会话日志
脚本工具
^^^^^^^^^^^^^^^^
- 长连接状态
20181128整理需求实现
===============================
tcp长连接状态
--------------------