運用・保守開発プラクティス - Sentryのモニタリングシステムを構築するために、エラーログに基づいて

エラー・ログ監視も誘導収集し、監視アラームの操作によって生成されたビジネス・プロセス・システム・エラー・ログ用に設計されたビジネス・ロジック・モニター呼び出すことができます。デジャヴがあるように思えますか？はい...それがに記載されている「APMアプリケーションパフォーマンス監視。」しかし、それはAPMと異なり、APMシステムは、主にアプリケーション層の行動分析に焦点を当て、より多くのデータの収集は、動作方向です。そして見張り行われ、トラブルシューティングコードを容易にするため、アプリケーションコードの基礎となるクラッシュの情報を収集することですコードレノン例外です。簡単に言えば、それは技術指向のコードレノンのトラブルシューティングツールです。

1.シーン記述

プロセスの自動化の運用・保守の進歩によって、ツールやシステムのさまざまな種類の操作やメンテナンスが生まれている。現在、当社の独立動作の開発・保守システムの数が。二桁に近いされているこれらのシステムは、複数のマシンに展開され、通常は支持しますバックグラウンドで実行されているスクリプトの数。例外が発生した場合、ウェブが終了し、開発者はそれを修正するためのタイムリーなフィードバックを受け取ることができます。スクリプトの相互作用がないので、状況が問題にするときの主要な故障箇所を発生することがあります。

2.既存のプログラム

1. 後端と中間状態内蔵ログ記録スクリプトプログラムPythonモジュールを使用してだけでなく、捕捉されない例外情報の指定されたファイルの両方の出力をリダイレクトします。

2. 同じディレクトリに集中格納された複数のサーバーを持つシステムにログオンします

3. 複数のサーバからのタイミングプルrsyncのログファイルを使用します

4. ログファイルには、キーワードマッチングされ、電子メールでの操作や保守開発者に送信された結果を絞り込みます

電子メール通知の図の最終統合

3.問題

上記の動作状態を実行するスクリプトを監視死角の問題​​に対する部分的解決策が、問題があります

1. 間違った認識ではない最初の時間

   ウェブエンドユーザーからのフィードバックスクリプトは、多くの場合、ログに記録遅れではなく、リアルタイムに引き出します。問題解決サイクルに問題が長すぎる存在している、簡単に受動的に導きます。

2. エラーメッセージが比較的非効率的な取得

   エラーメッセージや電子メールアラートは、ユーザーからのフィードバックは非常に限られている含まれているが、最終的にログに関連付けられた大量の情報を見下ろすする必要がありました。コードも問題原因を突き止めるために、テスト環境では、いくつかの中間の埋葬多変数データを取得する必要があるかもしれません多くの問題。

3. ログのアプローチは十分に柔軟ではありません

   一般的にエラーを実行するだけでなく、我々はまた、このようなデータの汚染などの他の異常な状況、気に言えば、不正な要求、サードパーティのAPIは、記録されたような同等のエラーがアラームスパムを生じさせる可能性がある場合。異常を呼び出し、そうでない場合に対処しますそのような異常は、時間の経過とともに深刻な問題を引き起こす可能性があります。私たちは同じログの内容が異なるシナリオに応じて柔軟にすることができますしたいです

4. 監視範囲は限られ

   モニタリングは、フロントとリアの終了後の分離を達成するために完全なスクリプト、バックエンドと三つの部分の先端部、特に私たちの新しい運用・保守システムをカバーする必要があり、多くの問題の先端が統一を記録することができません。

そこで、私たちは歩哨を選択し、ログ収集と監視プログラムのいくつかを理解しています。

見張り4.

4.1概要

Sentryは、現代、エラーログおよびアグリゲーションプラットフォームです。に示すように、それは、ほぼすべての主要な開発言語やプラットフォームをサポートしており、近代的なUIを提供しています

そしてELK、異なるSplunkは、公式SDKによって生成されたアプリケーションエラーログの集約と監視の見張り焦点は、言語の数を提供します。

30統合的な方法まで

最初の時間は、開発者は、エラーメッセージを確認し、簡単に自分自身とチームのワークフローに統合することができます。

コントラストの使用前と後4.2

一般的なシナリオをシミュレートし、強力な歩哨、を視覚的に表示するために、任意の類似性は純粋な偶然です。

4.2.1シーンワン

かつての歩哨にアクセス

• ユーザーA：パブリッシングはかかりません。

• 開発者A :?どのページの図をカット

• ユーザーA：（スクリーンショットの脂肪）

• バグを再現することができ、開発者が発見された、プログラム・ロジック、何の問題を確認し、データベースのデータをチェックするために、サーバーのエラーログを表示するには、ログインし、我々はダーティデータを見つけました。PythonスクリプトC.py.をチェックするためにデータBを更新するための責任ある開発者にお問い合わせください

• 開発者Bのログオンサーバーロジックエラーがストライキにスクリプトが時間続いた原因を見つける、エラーログを表示します。データの数千人に影響を与えます

アクセスした後、

• 開発者Aは、Bが同時に分前スクリプトC.pyが予期せず終了、電子メールアラートを受け取ります。

• 開発者Bは、エラーメッセージを参照してください、問題を見つけて、それを修正し、データの影響を受けた数十人をクリーンアップするために舞台裏歩哨を入力します。

• いいえ、ユーザーは、開発者の介入なしにAこのプロセスの間に影響はありません

4.2.2シーンII

かつての歩哨にアクセス

• ユーザー：ポイント送信ボタンが応答しませんでした

• 開発者:?切り取りページの図

• ユーザー：（脂肪ショット）

• 開発者：私は、ここではこの問題を持っていないあなたが開発者向けツールを開いて、コンソールパネルにカットし、私は見て数字をカット

• ユーザー：どのように取得するには？

  ….省略100字

• 开发者拿到相关数据, 确定是代码问题. 但是js文件经过了压缩, 无法定位到有问题的代码. 只能打开本地开发服务器调试.

接入后

• 开发者收到邮件告警, 显示前端有错误日志

• 开发者进入sentry后台查看错误信息, 比如用户浏览器版本, 产生错误的页面url, 代码调用过程和最终引发错误的代码, 确认问题所在.

• 开发者: 两分钟前你提交的工单备注字段的校验有点问题, 你先把那一栏留空再提交, 稍后我会更新一个hotfix版本, 到时跟你说下.

• 用户: 好的, 刚想问.

5. sentry的配置

sentry官方提供了详细的部署文档, 网上也可以搜索到中文的安装教程, 安装过程不赘述. 想要尝鲜的小伙伴也可以直接使用sentry官方提供的saas, 免费版支持每天5000个event. 地址是 https://sentry.io

5.1 概念

使用sentry, 需要弄清楚几个概念:

• event

  直译是"事件", 是可操作数据的基本单位. 每一次日志输出就产生一个event. event并不一定就是错误, 如果日志记录级别设置很低, 那么后台会产生很多的event, 所以正确的设置日志级别很重要

• issue

  直译是"工单"或者"问题", 是同一类event的聚合. 某一个错误可能因为重复执行而被记录多出, 在sentry会自动聚合到一起, 方便处理. 通常我们操作的对象就是issue

  

• DSN

  DSN即客户端密钥, 用来进行客户端和服务器的通信. DSN是一个url, 包含一个公钥一个私钥, 项目标记和服务器地址, 比如https://1703147af2094458bevb1bfadcfa1c2:[email protected]/1545. 这类DSN是私密的, 还有一类是非私密的, 在sentry后台中显示为DSN(public), 给前端项目使用.

• Raven

  整个错误日志监控系统包括客户端和服务端, Sentry是服务端的名称, 客户端名称是Raver, 需要两者配合才能工作.

5.2 配置

sentry服务端的配置主要是名称, 告警规则等, 至于被监控项目是前端还是后端区别不大.

5.2.1 创建项目

1. 进入sentry系统后台, 点击右上角新建项目

   

2. 命名为[项目名][前|后端], 比如"蓝海前端".

3. 在配置应用框架页面, 点击可以查看各个语言或框架的接入文档(可以忽略这一步)

4. 点击左上角项目名称, 进入项目首页, 可以看到页面显示"Waiting for events…"

5.2.2 获取和测试DSN

1. 在"项目设置"页, 在左侧列表中点击"客户端密钥", 进入页面

2. 拷贝DSN, 后端的是DSN, 前端是DSN(public)

3. 以python为例, 执行pip install raven安装客户端后, 执行raven test DSN, 如果一切顺利, 可以在sentry后台项目首页看到新增了一条测试消息

   

5.2.3 配置警报

1. 在"项目设置"页面, 在左侧列表中点击"警报", 进入警报配置页

2. 点击规则标签页, 可以看到已有一个规则, 当事件首次发生时告警

3. 根据需要修改规则

告警规则的配置相当灵活, 且可以对多个条件进行与或判断

5.2.4 集成告警

1. 在"项目设置"页面, 在左侧列表中点击"所有集成"

2. 勾选需要接入的类型,比如Mail

   

邮件服务器的配置请参考官方文档, 自己搭建的sentry服务器如果发现集成类型很少, 可以安装官方或第三方插件进行扩展

在服务端配置结束后, 可以开始配置客户端.

6. 后端的接入

因为我们的系统主要用python开发, 在此以python为例.

python接入sentry十分简单. 官方提供了十几种python环境(框架)下使用sentry的例子, 比如在celery中

from raven import Clientfrom raven.contrib.celery import register_signal, register_logger_signalclient = Client(DSN)# register a custom filter to filter out duplicate logsregister_logger_signal(client)# The register_logger_signal function can also take an optional argument# `loglevel` which is the level used for the handler created.# Defaults to `logging.ERROR`register_logger_signal(client, loglevel=logging.INFO)# hook into the Celery error handlerregister_signal(client)# The register_signal function can also take an optional argument# `ignore_expected` which causes exception classes specified in Task.throws# to be ignoredregister_signal(client, ignore_expected=True)

个人推荐借鉴logging使用的例子, 原因是通常开发者会根据logging模块定制自己的日志配置, 不直接使用框架内的日志模块. 如果你在应用程序中只用了logging模块, 那么接入sentry对已存在的代码来说是透明的, 无需多加修改.

用logging模块接入sentry只需两步:

6.1 安装客户端

pip install raven

6.2 初始化配置

在应用程序的入口文件(tornado中的app.py等)中, 或者自定义的日志模块中, 插入如下代码

from raven.handlers.logging import SentryHandlerfrom raven.conf import setup_logginghandler = SentryHandler(DSN)handler.setLevel(logging.ERROR)setup_logging(handler)

完成了这两步操作之后, 就可以像之前那样使用logging模块

import logginglogger = logging.getLogger(__name__)logger.info('This is a test message')

当上面的代码被执行时, 除了原有的打log操作之外, raven还会向sentry服务器发送日志内容, 并向标准输出添加

Sending message of length xxx to https://xxxx

如果希望向sentry发送更多上下文信息, 可以带上extra参数

logger.error('This is a test message', extra={'stack': True})

最终显示在后台的日志信息如图

包含了日志级别, python环境信息, SDK信息, 栈调用, 前后n次日志输出, 相关的其他事件等等, 如果是未捕获的异常或带上extra参数, 还会显示中间变量的值, 很方便的定位到出错的位置和数据, 无需再去代码埋点.

7. 前端的接入

前端的接入相对来说复杂一些

第一, 需要对sentry服务器的域名进行解析. 内部的系统, 后端监控可以给线上机器添加hosts指定sentry服务器的IP. 而前端, 因为错误日志是从用户浏览器发出的, 需要用户能自动解析sentry服务器的域名

第二, 如果前端项目用到了打包工具, 而通常打包工具会对代码进行压缩甚至混淆, 就会出现sentry收集到的日志无法准确定位问题代码的情况 所幸, sentry支持导入sourcemap自动解析和还原代码, 让开发者在后台能看到development环境一样详细的栈调用. (当然如果没有用打包工具可以忽略这一步)

前端的接入这里以reactjs为例

7.1 安装依赖

npm i raven-js --save

7.2嵌入raven

在index.js文件(入口文件)中,

import Raven from 'raven-js';# 在适当的地方加入, 尽可能让它早执行Raven.config(DSN(public)).install();

其他前端框架的接入请参考官方文档 https://docs.sentry.io/clients/java

7.3导入sourcemap

提前生成好sourcemap文件, 实测source-map级别可以完美工作, cheap-source-map能定位到, 但显示不友好. 当然, 最推荐的是cheap-module-source-map

# 安装npm i -g sentry-cli-binary# 登录sentrysentry-cli --url SENTRY_URL login# SENTRY_URL指自建服务或官方saas地址, 执行命令后会访问API TOKEN创建页面, 生成一个TOKEN, 拷贝进来, 成功后TOKEN会被保留到系统用户某个配置目录下, 后续的请求都会重复使用这个TOKEN# 创建一个releasesentry-cli releases -o sentry -p 7d04f2c51f32 new test01 --finalize# 这里的sentry 和7d04f2c51f32 是指 组织名称和项目名称, 均指*简称*, 与sentry页面上默认显示的不同, 需要到配置页面查看# 上传dist目录下的文件sentry-cli releases -o sentry -p 7d04f2c51f32 files test01 upload-sourcemaps dist# 删除旧的release下的所有文件sentry-cli releases -o sentry -p 7d04f2c51f32 files test01 delete --all# 当然这个命令是不想要release上的文件的时候执行的

注意, 生成的map文件与上传的相对路径需要一致. 比如, dist目录是打包后的文件存放目录, map文件为sourcemap/[file].map, 则sentry-cli上传目录应该是dist, 这样map文件才会显示在sentry后台的~/sourcemap/目录下.

这样的webpack配置

devtool = 'source-map';output.path: 'dist';output.sourceMapFilename = 'sourcemap/[file].map';

则对应这样的命令

sentry-cli releases -o sentry -p 7d04f2c51f32 files test02 upload-sourcemaps dist

另外, sentry-cli提供了一个参数--url-prefix, 可以为上传的map文件添加前缀, 默认是~/, 有兴趣的同学可以试试看

再补充一点, sentry需要根据js文件的sourceMappingURL来解析map文件路径, 所以sourcemap级别不能用hide-source-map或者类似的.

代码上传完毕后, 在版本->工件页面可以看到该release上的文件, 如图

最终错误日志效果如图

8. sentry管理后台的使用

篇幅所限, sentry后台的使用简要讲几点

第一，自定义过滤

sentry提供了丰富的过滤选项, 默认过滤条件是"Unresolved Issues", 用户也可以自己组合过滤条件, 并保存成个人或团队的默认选项

第二，页面实时更新

上图中间的按钮可以开启或关闭issues页面的实时刷新,

第三，统计和概览

上图是系统管理员页面, 可以看到系统调用, 等待中的任务队列等的情况, 在个人帐号首页也能看到项目的统计信息.

9. 需要注意的点

1. 用sentry做错误日志监控不能取代原有的日志存储方案, 只是在日志收集和监控方面做了扩展. 使用sentry应着重利用其实时性和快捷性, 做到快速响应. sentry会清除较旧的日志内容, 这与ELK之类的日志处理系统也有差别.

2. sentry能否用得好还取决于打log的开发者的功力. 如果原始日志记录缺少关键信息或无效信息过多, 再强大的日志分析系统也无能为力. 因此在引入sentry做日志监控的同时, 也要同步加强开发团队打log的意识, 规范日志级别, 格式和内容