前端異常監控 Sentry 的私有化部署和使用

Sentry 爲一套開源的應用監控和錯誤追蹤的解決方案。這套解決方案由對應各類語言的 SDK 和一套龐大的數據後臺服務組成。應用須要經過與之綁定的 token 接入 Sentry SDK 完成數據上報的配置。經過 Sentry SDK 的配置，還能夠上報錯誤關聯的版本信息、發佈環境。同時 Sentry SDK 會自動捕捉異常發生前的相關操做，便於後續異常追蹤。異常數據上報到數據服務以後，會經過過濾、關鍵信息提取、概括展現在數據後臺的 Web 界面中。

在完成接入後咱們就能夠從管理系統中實時查看應用的異常，從而主動監控應用在客戶端的運行狀況。經過配置報警、分析異常發生趨勢更主動的將異常扼殺在萌芽狀態，影響更少的用戶。經過異常詳情分析、異常操做追蹤，避免對客戶端應用異常兩眼一抹黑的狀態，更高效的解決問題。

這篇文章也將會從一鍵部署服務開始，經過解決部署過程當中遇到的問題，分享到完成前端應用監控和異常數據使用的整個詳細過程，但願會對你的部署和使用中遇到的問題有所幫助。

快速部署 Sentry 服務

Sentry 的管理後臺是基於 Python Django 開發的。這個管理後臺由背後的 Postgres 數據庫（管理後臺默認的數據庫，後續會以 Postgres 代指管理後臺數據庫並進行分享）、ClickHouse（存數據特徵的數據庫）、relay、kafka、redis 等一些基礎服務或由 Sentry 官方維護的總共 23 個服務支撐運行。可見的是，若是獨立的部署和維護這 23 個服務將是異常複雜和困難的。幸運的是，官方提供了基於 docker 鏡像的一鍵部署實現 getsentry/onpremise。

這種部署方式依賴於 Docker 19.03.6+ 和 Compose 1.24.1+

準備工做

Docker 是能夠用來構建和容器化應用的開源容器化技術。

Compose 是用於配置和運行多 Docker 應用的工具，能夠經過一個配置文件配置應用的全部服務，並一鍵建立和運行這些服務。

在準備好 linux 服務器以後，並按照官方文檔安裝好對應版本的 Docker 和 Compose 以後，將 onpremise 的源代碼克隆到工做臺目錄：

git clone https://github.com/getsentry/onpremise.git
# 切換到  20.10.1 版本，後續的分享將會基於這個版本進行
git checkout release/20.10.1

docker 鏡像加速

在後續部署的過程當中，須要拉取大量鏡像，官方源拉取較慢，能夠修改 docker 鏡像源，修改或生成 /etc/docker/daemon.json 文件：

{
  "registry-mirrors": ["鏡像地址"]
}

而後從新加載配置，並重啓 docker 服務：

sudo systemctl daemon-reload
sudo systemctl restart docker

一鍵部署

在 onpremise 的根路徑下有一個 install.sh 文件，只須要執行此腳本便可完成快速部署，腳本運行的過程當中，大體會經歷如下步驟：

1. 環境檢查
2. 生成服務配置
3. docker volume 數據卷建立（可理解爲 docker 運行的應用的數據存儲路徑的建立）
4. 拉取和升級基礎鏡像
5. 構建鏡像
6. 服務初始化
7. 設置管理員帳號（若是跳過此步，可手動建立）

在執行結束後，會提示建立完畢，運行 docker-compose up -d 啓動服務。

在使用不添加 -d 參數運行 docker-compose up 命令後，咱們能夠看到服務的啓動日誌，須要等待內部 web、relay、snuba、kafka 等所有啓動並聯動初始化後，服務纔算徹底啓動，此刻纔可使用默認端口訪問管理端默認服務地址，此時能夠進行域名配置，並將 80 端口解析到服務的默認端口上，即可以使用域名進行訪問。

第一次訪問管理後臺，能夠看到歡迎頁面，完成必填項的配置，便可正式訪問管理後臺。

• Root URL：異常上報接口的公網根地址（在作網絡解析配置時，後臺服務能夠配置到內網外網兩個域名，只將上報接口的解析規則 /api/[id]/store/ 配置到公網環境，保證數據不會泄密）。
• Admin Email：在 install.sh 階段建立的管理員帳號。
• Outbound email：這部份內容爲郵件服務配置，能夠先不配置。

完成這部分工做後，對服務沒有定製化需求的能夠跳至前端接入和使用部分。

docker 數據存儲位置修改

能夠看到在服務運行的過程當中，會在 docker volume 數據卷掛載位置存儲數據，如 Postgres、運行日誌等，docker volume 默認掛載在 /var 目錄下，若是你的 /var 目錄容量較小，隨着服務的運行會很快佔滿，須要對 docker volume 掛載目錄進行修改。

# 在容量最大的目錄下建立文件夾
mkdir -p /data/var/lib/
# 中止 docker 服務
systemctl stop docker
# 將 docker 的默認數據複製到新路徑下，刪除舊數據並建立軟鏈接，即便得存儲實際佔用磁盤爲新路徑
/bin/cp -a /var/lib/docker /data/var/lib/docker && rm -rf /var/lib/docker &&  ln -s /data/var/lib/docker /var/lib/docker
# 重啓 docker 服務
systemctl start docker

服務定製

一鍵部署的 Sentry 服務總會有不符合咱們使用和維護設計的地方，這個時候，就須要經過對部署配置的修改來知足本身的需求。

服務組成與運行機制

在經過 docker-compose 快速部署以後，咱們先來觀察下啓動了哪些服務，併爲後續的適配和修改分析下這些服務的做用，運行 docker 查看全部容器的命令：

docker ps

能夠看到如今啓動的全部服務，而且一些服務是使用的同一個鏡像經過不一樣的啓動參數啓動的，按照鏡像區分而且經過筆者的研究推測，各個服務的做用以下：

• nginx:1.16

  • sentry_onpremise_nginx_1：進行服務間的網絡配置

• sentry-onpremise-local：如下服務使用同一個鏡像，即便用同一套環境變量

  • sentry_onpremise_worker_1

    • 多是處理後臺任務，郵件，報警相關

  • sentry_onpremise_cron_1

    • 定時任務，不肯定是什麼定時任務，可能也是定時清理

  • sentry_onpremise_web_1

    • web 服務（UI + web api）
  • sentry_onpremise_post-process-forwarder_1

  • sentry_onpremise_ingest-consumer_1

    • 處理 kafka 消息

• sentry-cleanup-onpremise-local

  • sentry_onpremise_sentry-cleanup_1

    • 數據清理，暫時不重要，可是應該和其餘的 sentry 服務公用一些配置

  • sentry_onpremise_snuba-cleanup_1

    • 數據清理，暫時不重要

• getsentry/relay:20.10.1

  • sentry_onpremise_relay_1

    • 來自應用上報的數據先到 relay，
    • relay 直接返回響應狀態
    • 後在後臺任務中繼續處理數據
    • 解析事件、格式調整、啓用過濾規則等丟棄數據
    • 數據寫入 kafka

• symbolicator-cleanup-onpremise-local

  • sentry_onpremise_symbolicator-cleanup_1

    • 數據清理的，暫時不重要

• getsentry/snuba:20.10.1

  • 看起來是消費 kafka 消息，往 ClickHouse 寫，用到了 redis，用途不明

  • sentry_onpremise_snuba-api_1

    • snuba 的接口服務，好像沒什麼做用

  • sentry_onpremise_snuba-consumer_1

    • 消費 Kafka 給 ClickHouse 提供事件

  • sentry_onpremise_snuba-outcomes-consumer_1

    • 消費 Kafka 給 ClickHouse outcomes

  • sentry_onpremise_snuba-sessions-consumer_1

    • 消費 Kafka 給 ClickHouse sessions

  • sentry_onpremise_snuba-replacer_1

    • 看起來是轉換老（或者別的轉換功能）數據的，從kafka拿後寫到kafka

• tianon/exim4

  • sentry_onpremise_smtp_1

    • 郵件服務

• memcached:1.5-alpine

  • sentry_onpremise_memcached_1
  • 也許是用來下降數據存儲的頻次和衝突的

• getsentry/symbolicator:bc041908c8259a0fd28d84f3f0b12daa066b49f6

  • sentry_onpremise_symbolicator_1

    • 最基礎的設施：解析（native）錯誤信息

• postgres:9.6

  • sentry_onpremise_postgres_1

    • 基礎的設施，服務後臺默認的數據庫，存儲異常數據

• confluentinc/cp-kafka:5.5.0

  • sentry_onpremise_kafka_1

    • 基礎的設施，ClickHouse 和 pg 的數據確定都是從 kafka 來的

• redis:5.0-alpine

  • sentry_onpremise_redis_1

    • 基礎的設施，有一些攔截配置在這

• confluentinc/cp-zookeeper:5.5.0

  • sentry_onpremise_zookeeper_1

    • 基礎的設施

• yandex/ClickHouse-server:19.17

  • sentry_onpremise_ClickHouse_1

    • 與pg不一樣的存儲，存儲是異常的關鍵信息，用於快速檢索

同時，根據異常上報到服務後，日誌的記錄狀況可知，運行機制大概以下：

• 異常數據經過 nginx 解析到 relay 服務。
• relay 經過 pg 獲取最新的應用與 token 匹配關係，並驗證數據中的 token，直接返回 403 或 200，並對數據進行攔截過濾。
• relay 將數據發送給 kafka 的不一樣 topic。
• sentry 訂閱其中部分 topic，解析數據存入 Postgres，用作後續查看錯誤詳情。
• snuba 訂閱其餘 topic，對數據打標籤，提取關鍵特徵，存入 ClickHouse，用來快速根據關鍵特徵檢索數據。

文件結構與做用

要對部署和運行進行修改的話，須要找到對應的配置文件，先看下 onpremise 部署實現的主要文件結構和做用：

• clickhouse/config.xml：clickhouse 配置文件
• cron/：定時任務的鏡像構建配置和啓動腳本
• nginx/nginx.conf：nginx 配置
• relay/config.example.yml：relay 服務配置文件

• sentry/：sentry-onpremise-local 鏡像的構建和基於此鏡像啓動的主服務的配置都在這個文件夾下

  • Dockerfile：sentry-onpremise-local 的鏡像構建配置，會以此啓動不少服務
  • requirements.example.txt：由今生成 requirements.txt，須要額外安裝的 Django 插件須要被寫在這裏面
  • .dockerignore：Docker 的忽略配置，初始忽略了 requirements.txt 以外的全部文件，若是構建新鏡像時須要 COPY 新東西則須要修改此文件
  • config.example.yml：由今生成 config.yml，通常放運行時不能經過管理後臺修改的配置
  • sentry.conf.example.py：由今生成 sentry.conf.py，爲 python 代碼，覆蓋或合併至 sentry 服務中，從而影響 sentry 運行。
• .env：鏡像版本、數據保留天數、端口等配置
• docker-compose.yml：Compose 工具配置，多 docker 的批量配置和啓動設置
• install.sh：Sentry 一鍵部署流程腳本

同時須要注意的是，一旦部署過以後，install.sh 腳本就會根據 xx.example.xx 生成實際生效的文件，並且，再次執行 install.sh 腳本時會檢測這些文件存不存在，存在則不會再次生成，因此須要修改配置後從新部署的狀況下，咱們最好將生成的文件刪除，在 xx.example.xx 文件中修改配置。

根據服務組成和運行機制得知，主服務是基於 sentry-onpremise-local 鏡像啓動的，而 sentry-onpremise-local 鏡像中的 sentry 配置會合並 sentry.conf.py，此文件又是由 sentry.conf.example.py 生成，因此後續定製化服務時，會重點修改 sentry.conf.example.py 配置模板文件。

使用獨立數據庫確保數據穩定性

在數據庫單機化部署的狀況下，一旦出現機器故障，數據會損壞丟失，而 onpremise 的一鍵部署就是以 docker 的形式單機運行的數據庫服務，且數據庫數據也存儲在本地。

能夠看到 Sentry 的數據庫有兩個，Postgres 和 ClickHouse。

雖然 Sentry 不是業務應用，在宕機後不影響業務正常運行，數據的穩定並非特別重要，可是 Postgres 中存儲了接入 Sentry 的業務應用的 id 和 token 與對應關係，在這些數據丟失後，業務應用必需要修改代碼以修改 token 從新上線。爲了不這種影響，且公司有現成的可容災和按期備份的 Postgres 數據庫，因此將數據庫切換爲外部數據庫。

修改 sentry.conf.example.py 文件中 DATABASES 變量便可：

DATABASES = {
  'default': {
    'ENGINE': 'sentry.db.postgres',
    'NAME': '數據庫名',
    'USER': '數據庫用戶名',
    'PASSWORD': '數據庫密碼',
    'HOST': '數據庫域名',
    'PORT': '數據庫端口號',
  }
}

因爲再也不須要以 Docker 啓動 Postgres 數據庫服務，因此將 Postgres 相關信息從 docker-compose.yml 文件中刪除。刪掉其中的 Postgres 相關配置便可。

depends_on:
    - redis
    - postgres # 刪除
# ...
services:
# ...
# 刪除開始
  postgres:
    << : *restart_policy
    image: 'postgres:9.6'
    environment:
      POSTGRES_HOST_AUTH_METHOD: 'trust'
    volumes:
      - 'sentry-postgres:/var/lib/postgresql/data'
# 刪除結束
# ...
volumes:
  sentry-data:
    external: true
  sentry-postgres: # 刪除
    external: true # 刪除

同時，因爲 Sentry 在啓動前，初始化數據庫結構的使用會 pg/citext 擴展，建立函數，因此對數據庫的用戶權限有必定要求，也須要將擴展提早啓用，不然會致使 install.sh 執行失敗。

控制磁盤佔用

隨着數據的上報，服務器本地的磁盤佔用和數據庫大小會愈來愈大，在接入300萬/日的流量後，磁盤總佔用天天約增長 1.4G-2G，按照 Sentry 定時數據任務的配置保留 90 天來講，全量接入後磁盤佔用會維持在一個比較大的值，同時這麼大的數據量對數據的查詢也是一個負擔。爲了減輕負擔，須要從服務端和業務應用端同時入手。綜合考慮咱們將數據保留時長改成 7 天。修改 .env 文件便可：

SENTRY_EVENT_RETENTION_DAYS=7

也能夠直接修改 sentry.conf.example.py：

SENTRY_OPTIONS["system.event-retention-days"] = int(
    env("SENTRY_EVENT_RETENTION_DAYS", "90")
)
# 改成
SENTRY_OPTIONS["system.event-retention-days"] = 7

須要注意的是，定時任務使用 delete 語句刪除過時數據，此時磁盤空間不會被釋放，若是數據庫沒有定時回收的機制，則須要手動進行物理刪除。

# 做爲參考的回收語句
vacuumdb -U [用戶名] -d [數據庫名] -v -f --analyze

單點登陸 CAS 登陸接入

Sentry 自己支持 SAML二、Auth0 等單點登陸方式，可是咱們須要支持 CAS3.0，Sentry 和 Django 沒有對此有良好支持的插件，因此筆者組裝了一個基本可用的插件 sentry_cas_ng。

使用時，須要進行插件的安裝、註冊和配置，插件使用 github 地址安裝，須要一些前置的命令行工具，就不在 requirements.txt 文件中進行配置，直接修改 sentry/Dockerfile 文件進行安裝，追加如下內容：

# 設置鏡像源加速
RUN echo 'deb http://mirrors.aliyun.com/debian/ buster main non-free contrib \n\
deb http://mirrors.aliyun.com/debian/ buster-updates main non-free contrib \n\
deb http://mirrors.aliyun.com/debian/ buster-backports main non-free contrib \n\
deb http://mirrors.aliyun.com/debian-security/ buster/updates main non-free contrib \n\
deb-src http://mirrors.aliyun.com/debian/ buster main non-free contrib \n\
deb-src http://mirrors.aliyun.com/debian/ buster-updates main non-free contrib \n\
deb-src http://mirrors.aliyun.com/debian/ buster-backports main non-free contrib \n\
deb-src http://mirrors.aliyun.com/debian-security/ buster/updates main non-free contrib' > /etc/apt/sources.list
# 升級和安裝前置工具
RUN apt-get update && apt-get -y build-dep gcc \
    && apt-get install -y -q libxslt1-dev libxml2-dev libpq-dev libldap2-dev libsasl2-dev libssl-dev sysvinit-utils procps
RUN apt-get install -y git
# 安裝這個基本可用的 cas 登陸插件
RUN pip install git+https://github.com/toBeTheLight/sentry_cas_ng.git

同時修改 sentry.conf.example.py 文件，以進行插件的註冊和配置項配置：

# 修改 session 庫，解決 session 較長的問題
SESSION_ENGINE = 'django.contrib.sessions.backends.db'
# 在 django 中安裝插件
INSTALLED_APPS = INSTALLED_APPS + (
    'sentry_cas_ng',
)
# 註冊插件中間件
MIDDLEWARE_CLASSES = MIDDLEWARE_CLASSES + (
    'sentry_cas_ng.middleware.CASMiddleware',
)
# 註冊插件數據管理端
AUTHENTICATION_BACKENDS = (
    'sentry_cas_ng.backends.CASBackend',
) + AUTHENTICATION_BACKENDS
 
# 配置 CAS3.0 單點登陸的登陸地址
CAS_SERVER_URL = 'https://xxx.xxx.com/cas/'
# 配置 cas 版本信息
CAS_VERSION = '3'
# 由於插件是使用攔截登陸頁強制跳轉至 SSO 頁面的方式實現的
# 因此須要配置登陸攔截作跳轉 SSO 登陸操做
# 須要將 pathReg 配置爲你的項目的登陸 url 的正則
# 同時，當頁面帶有 ?admin=true 參數時，不跳轉至 SSO
def CAS_LOGIN_REQUEST_JUDGE(request):
  import re
  pathReg = r'.*/auth/login/.*'
  return not request.GET.get('admin', None) and re.match(pathReg, request.path) is not None
# 配置登出攔截作登出操做
# 讓插件識別當前爲登出操做，銷燬當前用戶 session
# 爲固定內容，不變
def CAS_LOGOUT_REQUEST_JUDGE(request):
  import re
  pathReg = r'.*/api/0/auth/.*'
  return re.match(pathReg, request.path) is not None and request.method == 'DELETE'
# 是否自動關聯 sso cas 信息至 sentry 用戶
CAS_APPLY_ATTRIBUTES_TO_USER = True
# 登陸後分配的默認組織名稱，必須與管理端 UI 設置的組織名相同
AUTH_CAS_DEFAULT_SENTRY_ORGANIZATION = '[組織名]'
# 登陸後默認的角色權限
AUTH_CAS_SENTRY_ORGANIZATION_ROLE_TYPE = 'member'
# 登陸後默認的用戶郵箱後綴，如 @163.com 中的 163.com
AUTH_CAS_DEFAULT_EMAIL_DOMAIN = '[郵箱後綴]'

完成配置後，須要使用 Sentry 的默認組織名 sentry，訪問 xxx/auth/login/sentry?admin=true，避過 CAS 插件攔截，以管理員身份登陸，而後修改 Sentry 設置的組織名爲插件中的配置的組織名變量 AUTH_CAS_DEFAULT_SENTRY_ORGANIZATION 的值。不然新用戶經過 SSO 登陸後會因爲要分配的組織名和服務設置的組織名不匹配出現錯誤。

修改默認時區

在登陸 Sentry 以後，能夠發現異常的時間爲 UTC 時間，每一個用戶均可以在設置中將時區改成本地時區：

出於用戶友好考慮，能夠直接修改服務的默認時區，在 sentry.conf.example.py 文件中添加配置：

# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
SENTRY_DEFAULT_TIME_ZONE = 'Asia/Shanghai'

獲取真實 IP

Sentry 會獲取請求頭中 X-Forwarded-For （結構爲ip1,ip2,ip3）的第一個 IP 爲真實用戶 IP，Sentry 一鍵部署啓動的服務的最靠前的服務是一個 Nginx 服務，它的配置就是以前提到的 nginx/nginx.conf 文件，在其中能夠看到一行 proxy_set_header X-Forwarded-For $remote_addr;，其中 $remote_addr 表示「客戶端」 IP，可是這個客戶端是相對於 Nginx 服務的而言的，若是前面有其餘的代理服務器，那麼拿到的就是代理服務器的 IP。在咱們的部署環境中，X-Forwarded-For 由前置的 Nginx 服務提供，且已經處理成須要的格式，因此刪除此行便可。

角色權限修改

在 Sentry 的默認的角色權限系統中有如下名詞，在信息結構按照包含關係有組織、團隊、項目、事件。

在角色層面又具備：

• superuser：系統管理員（很是規角色），可刪除用戶帳號，在 install.sh 腳本執行時建立的帳號就是系統管理員。
• owner：組織管理員，在私有化部署的狀況下只有一個組織，便可以修改服務配置以外的信息，能夠控制組織及如下層面的配置、刪除。
• manager：團隊管理員，可從團隊中移除用戶，可建立刪除全部項目，可建立刪除全部團隊。
• admin：可進行項目的設置（如報警、入站規則），批准用戶加入團隊，建立團隊、刪除所在團隊，調整所在團隊的工程的配置。
• member：可進行問題的處理。

且角色是跟隨帳號的，也就是說，一個 admin 會在他加入的全部的團隊中都是 admin。

在咱們的權限設計中，但願的是由 owner 建立團隊和團隊下的項目，而後給團隊分配 admin。即 admin 角色管理團隊下的權限配置，可是不能建立和刪除團隊和項目。在 Sentry 的現狀下，最接近這套權限設計的狀況中，只能取消 admin 對團隊、項目的增刪權限，而沒法設置他只擁有某個團隊的權限。

在 Sentry 的配置中是這麼管理權限的：

SENTRY_ROLES = (
  # 其餘角色
  # ...
  {
    'id': 'admin',
    'name': 'Admin',
    'desc': '省略'
    'of.',
    'scopes': set(
      [
        "org:read","org:integrations",
        "team:read","team:write","team:admin",
        "project:read", "project:write","project:admin","project:releases",
        "member:read",
        "event:read", "event:write","event:admin",
      ]),
  }
)

其中 read、write 爲配置讀寫，admin 則是增刪，咱們只須要刪掉 "team:admin" 和 "project:admin" 後在 sentry.conf.example.py 文件中複寫 SENTRY_ROLES 變量便可。須要調整其餘角色權限能夠自行調整。

其餘配置修改

至此，咱們的定製化配置就完成了。

基本上全部的配置均可以經過在 sentry.conf.example.py 文件中從新賦值整個變量或某個字段的方式調整，有哪些配置項的話能夠去源代碼的 src/sentry/conf/server.py 文件中查詢，有其餘需求的話能夠自行嘗試修改。

前端接入和使用

後續的接入使用，咱們以 Vue 項目示範。

SDK 接入

首先須要進行對應團隊和項目的建立：

選取平臺語言等信息後，能夠建立團隊和項目：

npm i @sentry/browser @sentry/integrations

其中 @sentry/browser 爲瀏覽器端的接入 sdk，須要注意的是，它只支持 ie11 及以上版本的瀏覽器的錯誤上報，低版本須要使用 raven.js，咱們就再也不介紹。

@sentry/integrations 包裏是官方提供的針對前端各個框架的功能加強，後續會介紹。

在進行接入是，咱們必需要知道的是和你當前項目綁定的 DSN（客戶端祕鑰），可在管理端由 Settings 進入具體項目的配置中查看。

import * as Sentry from '@sentry/browser'
import { Vue as VueIntegration } from '@sentry/integrations'
import Vue from 'vue'

Sentry.init({
  // 高訪問量應用能夠控制上報百分比
  tracesSampleRate: 0.3,
  // 不一樣的環境上報到不一樣的 environment 分類
  environment: process.env.ENVIRONMENT,
  // 當前項目的 dsn 配置
  dsn: 'https://[clientKey]@sentry.xxx.com/[id]',
  // 追蹤 vue 錯誤，上報 props，保留控制檯錯誤輸出
  integrations: [new VueIntegration({ Vue, attachProps: true, logErrors: true })]
})

能夠看到的是 VueIntegration 加強上報了 Vue 組件的 props，同時咱們還能夠額外上報構建的版本信息 release。此時，Sentry 已經開始上報 console.error、ajax error、uncatch promise 等信息。同時，咱們還能夠進行主動上報、關聯用戶。

Sentry.captureException(err)
Sentry.setUser({ id: user.id })

Sentry 還提供了基於 Webpack 的 plugin：webpack-sentry-plugin 幫助完成接入，就再也不作介紹。

如何使用監控數據

進入某個具體的項目後，能夠看到 Sentry 根據錯誤的 message、stack、發生位置進行概括分類後的 Issue 列表：

在右側，能夠看到每一個錯誤的發生趨勢、發生次數、影響用戶數和指派給誰解決這個問題的按鈕。咱們能夠經過這些指標進行錯誤處理的優先級分配和指派。

經過發展趨勢，咱們也能夠觀察到是否與某次上線有關，還能夠經過左側的 Discover 建立自定義的趨勢看板，更有針對性的進行觀察。

點擊進入每一個 issue 後，能夠看到詳細信息：

從上到下，能夠看到錯誤的名稱，發生的主要環境信息，Sentry 提取的錯誤特徵，錯誤堆棧，在最下面的 BREADCRUMBS 中能夠看到異常發生前的前置操做有哪些，能夠幫助你進行問題操做步驟的還原，協助進行問題排查。

Sentry 的入門使用到此爲止。其餘的功能，如報警配置、性能監控能夠自行探索。

招聘

做爲智聯招聘的前端架構團隊，咱們一直在尋找志同道合的先後端架構師和高級工程師，若是您也和咱們同樣熱愛技術、熱愛學習、熱愛探索，就請加入咱們吧！請將簡歷請發送至郵箱zpfe@group.zhaopin.com.cn，或者微信掃碼溝通。