关于前端:前端异常监控-Sentry-的私有化部署和使用

Sentry 为一套开源的利用监控和谬误追踪的解决方案。这套解决方案由对应各种语言的 SDK 和一套宏大的数据后盾服务组成。利用须要通过与之绑定的 token 接入 Sentry SDK 实现数据上报的配置。通过 Sentry SDK 的配置，还能够上报谬误关联的版本信息、公布环境。同时 Sentry SDK 会主动捕获异样产生前的相干操作，便于后续异样追踪。异样数据上报到数据服务之后，会通过过滤、要害信息提取、演绎展现在数据后盾的 Web 界面中。

在实现接入后咱们就能够从管理系统中实时查看利用的异样，从而被动监控利用在客户端的运行状况。通过配置报警、剖析异样产生趋势更被动的将异样扼杀在萌芽状态，影响更少的用户。通过异样详情剖析、异样操作追踪，防止对客户端利用异样两眼一抹黑的状态，更高效的解决问题。

这篇文章也将会从一键部署服务开始，通过解决部署过程中遇到的问题，分享到实现前端利用监控和异样数据应用的整个具体过程，心愿会对你的部署和应用中遇到的问题有所帮忙。

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 镜像源，批改或生成 /etc/docker/daemon.json 文件：

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

而后从新加载配置，并重启 docker 服务：

sudo systemctl daemon-reload
sudo systemctl restart docker

在 onpremise 的根门路下有一个 install.sh 文件，只须要执行此脚本即可实现疾速部署，脚本运行的过程中，大抵会经验以下步骤：

环境查看
生成服务配置
docker volume 数据卷创立（可了解为 docker 运行的利用的数据存储门路的创立）
拉取和降级根底镜像
构建镜像
服务初始化
设置管理员账号（如果跳过此步，可手动创立）

在执行完结后，会提醒创立结束，运行 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 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

Sentry 自身反对 SAML2、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'

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 我的项目示范。

首先须要进行对应团队和我的项目的创立：

选取平台语言等信息后，能够创立团队和我的项目：

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，或者微信扫码沟通。

关于前端:前端异常监控-Sentry-的私有化部署和使用

疾速部署 Sentry 服务

筹备工作

docker 镜像减速

一键部署

docker 数据存储地位批改

服务定制

服务组成与运行机制

文件构造与作用

应用独立数据库确保数据稳定性

管制磁盘占用

单点登录 CAS 登录接入

批改默认时区

获取实在 IP

角色权限批改

其余配置批改

前端接入和应用

SDK 接入

如何应用监控数据

招聘

Just My Socks（注册教程内含优惠码）

关于前端:前端异常监控-Sentry-的私有化部署和使用

疾速部署 Sentry 服务

筹备工作

docker 镜像减速

一键部署

docker 数据存储地位批改

服务定制

服务组成与运行机制

文件构造与作用

应用独立数据库确保数据稳定性

管制磁盘占用

单点登录 CAS 登录接入

批改默认时区

获取实在 IP

角色权限批改

其余配置批改

前端接入和应用

SDK 接入

如何应用监控数据

招聘

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）