Sentry 開發者貢獻指南 - 後端服務(Python/Go/Rust/NodeJS)

為少發表於2021-12-17
後端PythonGoRustNodeJS

內容整理自官方開發文件

系列

目錄

  • 服務管理 (devservices)
    • 檢視服務的日誌
    • 為 redis、postgres 和 clickhouse 執行 CLI 客戶端
    • 移除容器狀態
  • 埠分配
    • 找出您的機器上正在執行的內容
  • 非同步 Worker
    • 註冊任務
    • 執行 Worker
    • 啟動 Cron 程式
    • 配置 Broker
      • Redis
      • RabbitMQ
  • Email
    • 出站 Email
    • 入站 Email
      • Mailgun
  • 節點儲存
    • Django 後端
    • 自定義後端
  • 檔案儲存
    • 檔案系統後端
    • Google Cloud 儲存後端
    • Amazon S3 後端
    • MinIO S3 後端
  • 時間序列儲存
    • RedisSnuba 後端（推薦）
    • Dummy 後端
    • Redis 後端
  • 寫 Buffer
    • 配置
      • Redis
  • 指標
    • Statsd 後端
    • Datadog 後端
    • DogStatsD 後端
    • Logging 後端
  • 配額
    • 事件配額
      • 配置
      • 全系統速率限制
      • 基於使用者的速率限制
      • 基於專案的速率限制
    • Notification 速率限制
      • 配置
  • Notification 摘要
    • 配置
    • 後端
      • Dummy 後端
      • Redis 後端
      • 示例配置
  • Relay
  • Snuba
  • 後端 Chart 渲染
    • 在 Sentry 的後端使用 Chartcuterie
    • 配置 chart 以進行渲染
      • 服務初始化
      • 新增/刪除 chart 型別
    • 在開發中執行 Chartcuterie
      • 在本地更新 chart type
  • 工作原理
    • Chartcuterie 啟動
    • 來自 Sentry 的 Render 呼叫

服務管理 (devservices)

Sentry 為 Docker 提供了一個抽象，以在開發中執行所需的服務，稱為 devservices。

Usage: sentry devservices [OPTIONS] COMMAND [ARGS]...

  Manage dependent development services required for Sentry.

  Do not use in production!

Options:
  --help  Show this message and exit.

Commands:
  attach  Run a single devservice in foreground, as...
  down    Shut down all services.
  rm      Delete all services and associated data.
  up      Run/update dependent services.

檢視服務的日誌

# Follow snuba logs
docker logs -f sentry_snuba

為 redis、postgres 和 clickhouse 執行 CLI 客戶端

# redis
docker exec -it sentry_redis redis-cli

# clickhouse
docker exec -it sentry_clickhouse clickhouse-client

# psql
docker exec -it sentry_postgres psql -U postgres

移除容器狀態

如果你真的搞砸了你的容器或卷，你可以使用 devservices rm 重新開始。

# 刪除與所有服務關聯的所有資料（容器、卷和網路）
sentry devservices rm

例如，假設我們在進行遷移時設法損壞了 postgres 資料庫，並且您想重置 postgres 資料，您可以執行以下操作：

# 刪除與單個服務關聯的所有資料（容器、卷和網路）
sentry devservices rm postgres

埠分配

以下是 Sentry 服務使用的埠或開發設定中 Sentry 服務的任何依賴項的簡單列表。它有兩個目的：

  • 找出為什麼在您的工作機器上使用埠以及殺死哪個程式以使其空閒。
  • 找出哪些埠可以安全地分配給新服務。
Port Service Description
9000 Clickhouse Devservice clickhouse. Snuba 的資料庫。
8123 Clickhouse
9009 Clickhouse
3021 Symbolicator Devservice symbolicator. 用於處理堆疊跟蹤。
1218 Snuba Devservice snuba. 用於搜尋事件。
9092 Kafka Devservice kafka. 用於 relay-sentry 通訊和可選的用於 sentry-snuba 通訊
6379 Redis Devservice redis （或者可能通過 rustier 設定中的 Homebrew 安裝），負責快取、relay 專案配置和 Celery 佇列
5432 Postgres Devservice postgres（或者可能通過 rustier 設定中的 Homebrew 安裝）
7899 Relay Devservice relay. 為 SDK 提供將事件傳送到的 API（也稱為事件攝取event ingestion）。Webpack 在 8000 埠反向代理到此伺服器。使用 sentry devserver 啟動/停止。
8000 Sentry Dev Sentry API +前端。Webpack 監聽此埠並代理 API 請求 Django app
8001 uWSGI 使用 sentry devserver 啟動/停止。為 Django app/API 提供服務。Webpack 在 8000 埠反向代理到此伺服器。
7999 Sentry frontend prod proxy 用於測試針對 prod API 的本地 UI 更改
8000 Develop docs 圍繞本文件的網站。 與 Sentry Dev 的衝突。
3000 User docs 面向使用者的文件。如果 Relay 在 devservice 之外執行，則可能與 Relay 衝突。
9001 Sentry Dev Styleguide server 執行 sentry devserver --styleguide 時繫結
9000 sentry run web sentry run web 的傳統預設埠，更改為 9001 以避免與 Clickhouse 衝突。
9001 sentry run web 沒有 webpack 或 Relay 的準系統前端。Sentry Dev 可能更好。與 Sentry Dev Styleguide server 衝突。
8000 Relay mkdocs documentation 在某些時候，這將合併到我們現有的文件儲存庫中。與 Sentry Dev 的衝突。

找出您的機器上正在執行的內容

  • 使用 lsof -nP -i4 | grep LISTEN 在 macOS 上查詢被佔用的埠。
  • Docker for Mac 的 Dashboard UI 顯示您正在執行的 docker 容器/開發服務以及分配的埠和啟動/停止選項。

非同步 Worker

Sentry 帶有一個內建佇列，以更非同步的方式處理任務。
例如，當一個事件進入而不是立即將其寫入資料庫時，它會向佇列傳送一個 job，以便可以立即返回請求，並且後臺 worker 會實際處理儲存該資料。

Sentry 依賴 Celery 庫來管理 worker。

  • ttps://docs.celeryproject.org/

註冊任務

Sentry 使用特殊的裝飾器配置任務，使我們能夠更明確地控制可呼叫物件。

from sentry.tasks.base import instrumented_task

@instrumented_task(
    name="sentry.tasks.do_work",
    queue="important_queue",
    default_retry_delay=60 * 5,
    max_retries=None,
)
def do_work(kind_of_work, **kwargs):
    # ...

有幾個重要的點：

  • _必須_宣告 task 名稱。

    Task 名稱是 Celery 如何識別訊息（請求）以及需要哪個函式和工作執行緒來處理這些訊息。
    如果 task 沒有命名，celery 將從模組和函式名稱派生一個名稱，
    這使得名稱與程式碼的位置相關聯，並且對於未來的程式碼維護更加脆弱。

  • Task 必須接受 \*\*kwargs 來處理滾動相容性。

    這確保 task 將接受恰好在佇列中的任何訊息，而不是因未知引數而失敗。
    它有助於回滾更改，部署不是即時的，並且可能會使用多個版本的引數生成訊息。

    雖然這允許在不完全任務失敗的情況下向前和向後滾動，
    但在更改引數時仍必須注意 worker 處理具有舊引數和新引數的訊息。
    這確實減少了這種遷移中所需更改的數量，併為 operator 提供了更多的靈活性，
    但是由於未知引數而導致的訊息丟失仍然是不可接受的。

  • Task _應該_在失敗時自動重試。

  • Task 引數_應該_是原始型別並且很小。

    Task 引數被序列化到通過 broker 傳送的訊息中，worker 需要再次反序列化它們。
    對複雜型別執行此操作是脆弱的，應該避免。例如。更喜歡將 ID 傳遞給 task，
    該 ID 可用於從快取而不是資料本身載入資料。
    Task 引數被序列化到通過 broker 傳送的訊息中，worker 需要再次對它們進行反序列化。
    對複雜型別執行此操作是脆弱的，應該避免。
    例如，寧願向 task 傳遞 ID，該 ID 可用於從快取載入資料，而不是資料本身。

    類似地，為了保持訊息 broker 和 worker 有效執行，
    將大值序列化到訊息中會導致大訊息、大佇列和更多（反）序列化開銷，因此應該避免。

  • 必須將 task 的模組新增到 CELERY_IMPORTS。

    src/sentry/conf/server.py.
    Celery worker 必須按 name 查詢 task，
    只有當 worker 匯入帶有裝飾任務函式的模組時才能這樣做，
    因為這是按 name 註冊 task 的內容。因此，每個包含 task 的模組都必須新增到 src/sentry/conf/server.py 中的 CELERY_IMPORTS 設定中。

執行 Worker

可以使用 Sentry CLI 執行 Worker。

$ sentry run worker

啟動 Cron 程式

Sentry 通過 cron 程式安排 routine job：

SENTRY_CONF=/etc/sentry sentry run cron

配置 Broker

Sentry 支援兩個主要 broker，可根據您的 workload 進行調整：RabbitMQ 和 Redis。

Redis

預設 broker 是 Redis，可以在大多數情況下工作。使用 Redis 的主要限制是所有待處理的工作都必須放在記憶體中。

BROKER_URL = "redis://localhost:6379/0"

如果您的 Redis 連線需要密碼進行身份驗證，則需要使用以下格式：

BROKER_URL = "redis://:password@localhost:6379/0"

RabbitMQ

如果您在 高 workload 下執行，或者擔心將待處理的 workload 放入記憶體中，那麼 RabbitMQ 是支援 Sentry worker 的理想選擇。

BROKER_URL = "amqp://guest:guest@localhost:5672/sentry"

Email

Sentry 提供對出站和傳入電子郵件的支援。

入站電子郵件的使用相當有限，目前僅支援處理對 error 和 note 通知的回覆。

出站 Email

您需要為出站電子郵件配置 SMTP 提供商。

TODO: 撰寫 mail 預覽後端。

mail.backend
在 `config.yml` 中宣告。

用於傳送電子郵件的後端。選項是 smtp、console 和 dummy。

預設為 smtp。如果您想禁用電子郵件傳送，請使用 dummy。

mail.from
在 `config.yml` 中宣告。

From header 中用於出站電子郵件的電子郵件地址。

預設為 root@localhost。強烈建議更改此值以確保可靠的電子郵件傳送。

mail.host
在 `config.yml` 中宣告。

用於 SMTP 連線的主機名。

預設為 localhost.

mail.port
在 `config.yml` 中宣告。

用於 SMTP 連線的連線埠。

預設為 25。

mail.username
在 `config.yml` 中宣告。

使用 SMTP 伺服器進行身份驗證時使用的使用者名稱。

預設為 (empty)。

mail.password
在 `config.yml` 中宣告。

使用 SMTP 伺服器進行身份驗證時使用的密碼。

預設為 (empty)。

mail.use-ssl
在 `config.yml` 中宣告。

Sentry 在連線到 SMTP 伺服器時是否應該使用 SSL？

預設為 false。

mail.use-tls
在 `config.yml` 中宣告。

Sentry 在連線到 SMTP 伺服器時應該使用 TLS 嗎？

預設為 false。

mail.list-namespace
在 `config.yml` 中宣告。

此 Sentry 伺服器傳送的電子郵件的郵件列表名稱空間。這應該是您擁有的域（通常與 mail.from 配置引數值的域部分相同）或 localhost。

入站 Email

對於配置，您可以從不同的後端進行選擇。

Mailgun

首先選擇一個域來處理入站電子郵件。我們發現如果您維護一個與其他任何事物分開的域，這是最簡單的。
在我們的示例中，我們將選擇 inbound.sentry.example.com。您需要根據 Mailgun 文件為給定域配置 DNS 記錄。

在 mailgun 中建立一個新路由：

Priority:
  0
Filter Expression:
  catch_all()
Actions:
  forward("https://sentry.example.com/api/hooks/mailgun/inbound/")
Description:
  Sentry inbound handler

使用適當的設定配置 Sentry：

# 您的 Mailgun API key（用於驗證傳入的 webhook）
mail.mailgun-api-key: ""

# 將 SMTP hostname 設定為您配置的入站域
mail.reply-hostname: "inbound.sentry.example.com"

# 通知 Sentry 傳送適當的郵件頭以啟用
# 收到答覆
mail.enable-replies: true

就是這樣！您現在可以通過電子郵件客戶端響應有關錯誤的活動通知。

節點儲存

Sentry 提供了一個名為 ‘nodestore’ 的抽象，用於儲存 key/value blob。

預設後端只是將它們作為 gzipped blob 儲存在預設資料庫的 ‘nodestore_node’ 表中。

Django 後端

Django 後端使用 gzipped json blob-as-text 模式將所有資料儲存在 ‘nodestore_node’ 表中。

後端不提供任何選項，因此只需將其設定為空字典即可。

SENTRY_NODESTORE = 'sentry.nodestore.django.DjangoNodeStorage'
SENTRY_NODESTORE_OPTIONS = {}

自定義後端

如果你有一個最喜歡的資料儲存解決方案，它只需要在一些規則下執行，它就可以與 Sentry 的 blob 儲存一起工作：

  • 設定 key/value
  • 獲取 key
  • 刪除 key

有關實現自己的後端的更多資訊，請檢視 sentry.nodestore.base.NodeStorage。

檔案儲存

Sentry 提供了一個名為 ‘filestore’ 的抽象，用於儲存檔案（例如釋出工件）。

預設後端將檔案儲存在不適合生產使用的 /tmp/sentry-files 中。

檔案系統後端

filestore.backend: "filesystem"
filestore.options:
  location: "/tmp/sentry-files"

Google Cloud 儲存後端

除了下面的配置之外，您還需要確保 shell 環境設定了變數 GOOGLE_APPLICATION_CREDENTIALS。
有關詳細資訊，請參閱 用於設定身份驗證的 Google Cloud 文件。

filestore.backend: "gcs"
filestore.options:
  bucket_name: "..."

Amazon S3 後端

S3 儲存後端支援使用 access key 或 IAM 例項角色進行身份驗證。
使用後者時，省略 access_key 和 secret_key。
預設情況下，S3 物件是使用 public-read ACL 建立的，這意味著除了 PutObject、GetObject 和 DeleteObject 之外，
所使用的帳戶/角色還必須具有 PutObjectAcl 許可權。
如果您不希望您上傳的檔案可公開訪問，您可以將 default_acl 設定為 private。

filestore.backend: "s3"
filestore.options:
  access_key: "..."
  secret_key: "..."
  bucket_name: "..."
  default_acl: "..."

MinIO S3 後端

filestore.backend: "s3"
filestore.options:
  access_key: "..."
  secret_key: "..."
  bucket_name: "..."
  endpoint_url: "https://minio.example.org/"

時間序列儲存

Sentry 提供儲存時間序列資料的服務。這主要用於顯示事件和專案的彙總資訊，以及（實時）計算事件發生率。

RedisSnuba 後端（推薦）

這是唯一一個 100% 正確工作的後端：

SENTRY_TSDB = 'sentry.tsdb.redissnuba.RedisSnubaTSDB'

該後端與 Snuba 通訊以獲取與事件攝取(event ingestion)相關的指標，並與 Redis 通訊以獲取其他所有內容。
Snuba 需要執行自己的結果消費者(outcomes consumer)，目前這不是 devservices 的一部分。

包裝的 Redis TSDB 可以這樣配置（有關 Redis 選項，請參閱下文）：

SENTRY_TSDB_OPTIONS = {
    'redis': ... # RedisTSDB 的選項字典在這裡
}

Dummy 後端

顧名思義，所有 TSDB 資料將在寫入時刪除並在讀取時替換為零：

SENTRY_TSDB = 'sentry.tsdb.dummy.DummyTSDB'

Redis 後端

“裸” Redis 後端讀取和寫入所有資料到 Redis。與事件攝取（Organization Stats）相關的各個列將顯示歸零資料，因為該資料僅在 Snuba 中可用。

SENTRY_TSDB = 'sentry.tsdb.redis.RedisTSDB'

預設情況下，這將使用名為 default 的 Redis 叢集。要使用不同的叢集，請提供 cluster 選項，如下所示：

SENTRY_TSDB_OPTIONS = {
    'cluster': 'tsdb',
}

寫 Buffer

Sentry 通過在一段時間內 buffer 寫入和重新整理對資料庫的批量更改來管理資料庫行爭用。 如果您具有高併發性，這將非常有用，尤其是當它們經常是同一個事件時。

例如，如果您碰巧每秒接收 100,000 個事件，並且其中 10% 向資料庫報告連線問題（它們將被組合在一起），
啟用 buffer 後端將改變事情，以便每個計數更新實際上是放入佇列中，所有更新都以佇列可以跟上的速度執行。

配置

要指定後端，只需修改配置中的 SENTRY_BUFFER 和 SENTRY_BUFFER_OPTIONS 值：

SENTRY_BUFFER = 'sentry.buffer.base.Buffer'

Redis

配置 Redis 後端需要佇列，否則您將看不到任何收益（事實上，您只會對效能產生負面影響）。

配置是直截了當的：

SENTRY_BUFFER = 'sentry.buffer.redis.RedisBuffer'

預設情況下，這將使用名為 default 的 Redis 叢集。要使用不同的叢集，請提供 cluster 選項，如下所示：

SENTRY_BUFFER_OPTIONS = {
    'cluster': 'buffer',
}

指標

Sentry 提供了一種稱為 ‘metrics’ 的抽象，用於內部監控，通常是計時和各種計數器。

預設後端只是丟棄它們（儘管某些值仍保留在內部時間序列資料庫中）。

Statsd 後端

SENTRY_METRICS_BACKEND = 'sentry.metrics.statsd.StatsdMetricsBackend'
SENTRY_METRICS_OPTIONS = {
    'host': 'localhost',
    'port': 8125,
}

Datadog 後端

Datadog 將要求您將 datadog 包安裝到您的 Sentry 環境中：

$ pip install datadog

在你的 sentry.conf.py 中：

SENTRY_METRICS_BACKEND = 'sentry.metrics.datadog.DatadogMetricsBackend'
SENTRY_METRICS_OPTIONS = {
    'api_key': '...',
    'app_key': '...',
    'tags': {},
}

安裝後，Sentry 指標將通過 HTTPS 傳送到 Datadog REST API。

DogStatsD 後端

使用 DogStatsD 後端需要一個 Datadog Agent 與 DogStatsD 後端一起執行（預設情況下在埠 8125）。

您還必須將 datadog Python 包安裝到您的 Sentry 環境中：

$ pip install datadog

在你的 sentry.conf.py 中：

SENTRY_METRICS_BACKEND = 'sentry.metrics.dogstatsd.DogStatsdMetricsBackend'
SENTRY_METRICS_OPTIONS = {
    'statsd_host': 'localhost',
    'statsd_port': 8125,
    'tags': {},
}

配置完成後，指標後端將傳送到 DogStatsD 伺服器，然後通過 HTTPS 定期重新整理到 Datadog。

Logging 後端

LoggingBackend 將所有操作報告給 sentry.metrics logger。
除了指標名稱和值之外，日誌訊息還包括額外的資料，例如可以使用自定義格式化程式顯示的 instance 和 tags 值。

SENTRY_METRICS_BACKEND = 'sentry.metrics.logging.LoggingBackend'

LOGGING['loggers']['sentry.metrics'] = {
    'level': 'DEBUG',
    'handlers': ['console:metrics'],
    'propagate': False,
}

LOGGING['formatters']['metrics'] = {
    'format': '[%(levelname)s] %(message)s; instance=%(instance)r; tags=%(tags)r',
}

LOGGING['handlers']['console:metrics'] = {
    'level': 'DEBUG',
    'class': 'logging.StreamHandler',
    'formatter': 'metrics',
}

配額

使用 Sentry 的工作方式，您可能會發現自己處於這樣一種情況：您會看到太多的入站流量，而沒有一個好的方法來丟棄多餘的訊息。對此有幾種解決方案，如果您遇到此問題，您可能希望全部使用它們。

事件配額

Sentry 中限制工作負載的主要機制之一涉及設定事件配額。這些可以在每個專案和系統範圍內進行配置，並允許您限制在 60 秒時間內接受的最大事件數。

配置

主要實現使用 Redis，只需要你配置連線資訊：

SENTRY_QUOTAS = 'sentry.quotas.redis.RedisQuota'

預設情況下，這將使用名為 default 的 Redis 叢集。要使用不同的叢集，請提供 cluster 選項，如下所示：

SENTRY_QUOTA_OPTIONS = {
    'cluster': 'quota',
}

如果您有其他需求，您可以像 Redis 實現一樣自由擴充套件基本 Quota 類。

全系統速率限制

您可以配置系統範圍的最大每分鐘速率限制：

system.rate-limit: 500

例如，在您專案的 sentry.conf.py 中，您可以執行以下操作：

from sentry.conf.server import SENTRY_OPTIONS


SENTRY_OPTIONS['system.rate-limit'] = 500

或者，如果您導航到 /manage/settings/，您將找到一個管理皮膚，其中包含一個用於設定 Rate Limit 的選項，該選項儲存在上述配額實施中。

基於使用者的速率限制

您可以配置基於使用者的每分鐘最大速率限制：

auth.user-rate-limit: 100
auth.ip-rate-limit: 100

基於專案的速率限制

要進行基於專案的速率限制，請單擊專案的 Settings。
在 Client Keys (DSN) tab 下，找到你想要限速的 key，點選對應的 Configure 按鈕。這應該會顯示 key/project-specific 的速率限制設定。

Notification 速率限制

在某些情況下，可能會擔心限制諸如出站電子郵件通知之類的內容。為了解決這個問題，Sentry 提供了一個支援任意速率限制的速率限制子系統。

配置

與事件配額一樣，主要實現使用 Redis：

SENTRY_RATELIMITER = 'sentry.ratelimits.redis.RedisRateLimiter'

預設情況下，這將使用名為 default 的 Redis 叢集。要使用不同的叢集，請提供 cluster 選項，如下所示：

SENTRY_RATELIMITER_OPTIONS = {
    'cluster': 'ratelimiter',
}

Notification 摘要

Sentry 提供了一項服務，該服務將在通知發生時收集通知，並安排它們作為聚合 “digest” 通知進行傳送。

配置

儘管 digest 系統配置了一組合理的預設選項，但可以使用 SENTRY_DIGESTS_OPTIONS 設定來微調 digest 後端行為，以滿足您獨特安裝的需要。
所有後端共享下面定義的一組通用選項，而某些後端還可能定義特定於其各自實現的附加選項。

minimum_delay: minimum_delay 選項定義了預設的最小時間量（以秒為單位），以在初始排程後在排程 digest 之間等待交付。這可以在 Notification 設定中按專案覆蓋。

maximum_delay: maximum_delay 選項定義了在排程 digest 之間等待傳送的預設最長時間（以秒為單位）。這可以在 Notification 設定中按專案覆蓋。

increment_delay: increment_delay 選項定義了在最後一次處理 digest 之後的 maximum_delay 之前，事件的每個觀察應該延遲排程多長時間。

capacity: capacity 選項定義了時間線內應包含的最大 item 數。這是硬限制還是軟限制取決於後端 - 請參閱 truncation_chance 選項。

truncation_chance: truncation_chance 選項定義了 add 操作觸發時間線截斷以使其大小接近定義容量的概率。值為 1 將導致時間線在每次 add 操作時被截斷（有效地使其成為硬限制），而較低的概率會增加時間線超過其預期容量的機會，但通過避免截斷來執行操作會提高 add 的效能，截斷是一項潛在的昂貴操作，尤其是在大型資料集上。

後端

Dummy 後端

Dummy 後端禁用摘要排程，所有通知都會在發生時傳送（受速率限制）。這是在版本 8 之前建立的安裝的預設 digest 後端。

可以通過 SENTRY_DIGESTS 設定指定 dummy 後端：

SENTRY_DIGESTS = 'sentry.digests.backends.dummy.DummyBackend'

Redis 後端

Redis 後端使用 Redis 來儲存 schedule 和待處理 notification 資料。這是自版本 8 以來建立的安裝的預設 digest 後端。

Redis 後端可以通過 SENTRY_DIGESTS 設定來指定：

SENTRY_DIGESTS = 'sentry.digests.backends.redis.RedisBackend'

Redis 後端接受基本集之外的幾個選項，通過 SENTRY_DIGESTS_OPTIONS 提供：

cluster : cluster 選項定義了應該用於儲存的 Redis 叢集。如果未指定叢集，則使用 default 叢集。

在將資料寫入 digest 後端後更改 cluster 值或叢集配置可能會導致意外影響 - 即，它會在叢集大小更改期間造成資料丟失的可能性。應在執行系統上小心調整此選項。

ttl : ttl 選項定義 record、timeline 和 digest 的生存時間（以秒為單位）。這可以（也應該）是一個相對較高的值，因為 timeline、digest 和 record 在處理後都應該被刪除——這主要是為了確保在配置錯誤的情況下過時的資料不會停留太久 . 這應該大於最大排程延遲，以確保不會過早驅逐資料。

示例配置

SENTRY_DIGESTS = 'sentry.digests.backends.redis.RedisBackend'
SENTRY_DIGESTS_OPTIONS = {
    'capacity': 100,
    'cluster': 'digests',
}

Relay

Relay 是一種用於事件過濾、速率限制和處理的服務。 它可以作為：

Snuba

後端 Chart 渲染

Sentry 的前端為使用者提供了各種型別的詳細互動式圖表，高度符合 Sentry 產品的外觀和感覺。
從歷史上看，這些圖表只是我們在 Web 應用程式中才有的東西。

然而，在某些情況下，在應用程式的某些上下文中顯示圖表非常有價值。例如

  • Slack 展開 Discover 圖表、指標警報通知、問題詳細資訊或 Sentry 中的任何其他連結，其中在 Slack 中檢視圖表可能很有用。

  • 通知和摘要電子郵件。將趨勢視覺化為圖表。

幸運的是，Sentry 為內部 Chartcuterie NodeJS 服務提供了內建功能，它可以通過 HTTP API 以影像格式生成圖形。
圖表是使用前端使用的相同 ECharts 庫生成的。
Chartcuterie 與 Sentry 的前端共享程式碼，這意味著可以在前端和後端 Chartcuterie 生成的圖表之間輕鬆維護圖表的外觀。

在 Sentry 的後端使用 Chartcuterie

使用 Chartcuterie 生成圖表非常簡單。

匯入 generate_chart 函式，提供 chart 型別和 data 物件，獲取公共圖片 URL。

from sentry.charts import generate_chart, ChartType

# The shape of data is determined by the RenderDescriptor in the
# configuration module for the ChartType being rendered.
data = {}

chart_url = generate_chart(ChartType.MY_CHART_TYPE, data)

配置 chart 以進行渲染

Chartcuterie 從 sentry.io 載入一個外部 JavaScirpt 模組，該模組決定了它如何呈現圖表。
該模組直接配置 EChart 的 options 物件，
包括在 POST /render 呼叫時提供給 Chartcuterie 的系列資料的轉換。

該模組作為 getsentry/sentry 的一部分存在，
可以在 static/app/chartcuterie/config.tsx 中找到。

服務初始化

可以配置一個可選的初始化函式 init 在服務啟動時執行。
這個函式可以訪問 Chartcuterie 的全域性 echarts 物件，
並且可以使用它來註冊實用程式（例如 registerMaps）。

新增/刪除 chart 型別

Chart 渲染是基於 每個 "chart type" 配置的。
對於每種型別的 chart，您都需要在前端應用程式和後端 chart 模組中宣告一個眾所周知的名稱。

  1. 在前端，在 static/app/charctuerie/types.tsx 中新增一個 ChartType。

  2. 在 static/app/chartcuterie/config.tsx中註冊 chart 的 RenderDescriptor，它描述了外觀和系列轉換。您可以為此使用 register 函式。

  3. 在後端，在 sentry.charts.types 模組中新增一個匹配的 ChartType。

  4. 在 Sentry 中部署您的更改。配置模組將在 5 分鐘內自動傳播到 Chartcuterie。

    您無需部署 Charcuterie。

不要在配置模組的同時部署使用新 chart type 的功能。由於存在傳播延遲，因此不能保證新 chart type 在部署後立即可用。

配置模組包括部署的 sentry.io 提交 SHA，它允許 Chartcuterie 在每個輪詢 tick 時檢查它是否收到了新的配置模組。

在開發中執行 Chartcuterie

要在本地開發人員環境中啟用 Chartcuterie，請首先在 config.yml 中啟用它：

# 啟用 charctuerie
chart-rendering.enabled: true

目前您需要在您的開發環境中手動構建配置模組。

yarn build-chartcuterie-config

然後您可以啟動 Chartcuterie devservice。如果 devservice 沒有啟動，
請檢查 chart-render.enabled key 是否正確設定為 true（使用 sentry config get chart-rendering.enabled）。

sentry devservices up chartcuterie

您可以通過檢查日誌來驗證服務是否已成功啟動

docker logs -f sentry_chartcuterie

應該是這樣的

info: Using polling strategy to resolve configuration...
info: Polling every 5s for config...
info: Server listening for render requests on port 9090
info: Resolved new config via polling: n styles available. {"version":"xxx"}
info: Config polling switching to idle mode
info: Polling every 300s for config...

您的開發環境現在已準備好呼叫 Chartcuterie 的本地例項。

在本地更新 chart type

當前，您需要在每次更改時使用 yarn build-chartcuterie-config 重建配置模組。 這在未來可能會得到改善。

工作原理

下面是 Chartcuterie service 的幾個 service 圖以及它如何與 Sentry 應用程式伺服器互動。

Chartcuterie 啟動

來自 Sentry 的 Render 呼叫

公眾號：黑客下午茶

相關文章