對(duì)于基本的健康跟蹤，Sentry 接受包含會(huì)話更新事件的 envelopes。這些會(huì)話更新事件可用于通知 Sentry 有關(guān) release 和 project 相關(guān) project 健康狀況的信息。

注意： 在本地使用 session 時(shí)，請(qǐng)確保使用必要的環(huán)境變量更新配置文件 ~/.sentry/sentry.config.py：

SENTRY_EVENTSTREAM = 'sentry.eventstream.kafka.KafkaEventStream'

基本操作

• Session 完全是 client 驅(qū)動(dòng)的。client 確定 session 何時(shí)開(kāi)始、結(jié)束或轉(zhuǎn)變?yōu)椴唤】禒顟B(tài)。
  • client 可以明確結(jié)束 session 以記錄時(shí)間或退出條件(崩潰等)。
  • 如果需要，client 應(yīng)在重新啟動(dòng)時(shí)明確結(jié)束 session，但 session 不結(jié)束是可以接受的。
• Session 通過(guò)保存整個(gè) session state 的會(huì)話更改事件進(jìn)行更新。
• Session 從發(fā)送的事件中更新。最近的事件保存整個(gè) session state。發(fā)送到服務(wù)器的初始 session event 被顯式標(biāo)記。
• Session 更新在實(shí)現(xiàn)時(shí)不得更改屬性或數(shù)據(jù)損壞。請(qǐng)參閱下面關(guān)于屬性不變性的部分。
• Session 只能更新 5 天。如果一個(gè)會(huì)話在 5 天內(nèi)沒(méi)有收到第二個(gè)事件，則永遠(yuǎn)是好的。
• Session 不一定要啟動(dòng)才崩潰。僅僅報(bào)告一次崩潰就足夠了。

服務(wù)器模型

目前，Sentry 的 session system 已針對(duì)易于擴(kuò)展性和操作成本進(jìn)行了優(yōu)化。這意味著該協(xié)議非常適合實(shí)現(xiàn)這一目標(biāo)。其中一些優(yōu)化顯示在協(xié)議中，client 準(zhǔn)確地遵循協(xié)議以避免在服務(wù)器上創(chuàng)建 bad data 非常重要。

服務(wù)器每小時(shí)都有預(yù)先物化(pre-materialized)的 session 數(shù)據(jù)。當(dāng)會(huì)話更新事件到來(lái)時(shí)，服務(wù)器將立即將數(shù)據(jù)具體化(materialize)到正確的存儲(chǔ)桶中。這意味著該協(xié)議僅限于“附加”。這也意味著 client 需要在其一側(cè)存儲(chǔ)會(huì)話的整個(gè)狀態(tài)。

會(huì)話更新負(fù)載

一個(gè) session update 是名為 session 的 envelope 中的一項(xiàng)。它包含一個(gè)大致如下所示的 JSON 負(fù)載：

{ 
  "sid": "7c7b6585-f901-4351-bf8d-02711b721929", 
  "did": "optional distinct user id", 
  "init": true, 
  "started": "2020-02-07T14:16:00Z", 
  "duration": 60, 
  "status": "exited", 
  "attrs": { 
    "release": "my-project-name@1.0.0", 
    "environment": "environment name", 
    "ip_address": "optional user ip address for filtering", 
    "user_agent": "optional user agent for filtering" 
  } 
} 

請(qǐng)注意，這必須包含在 envelope 中。所以完整的事件看起來(lái)像這樣：

{} 
{"type":"session"} 
{"sid":"..."} 

存在以下字段：

sid

• String, optional. 會(huì)話 ID (唯一的并且由客戶端生成的)。

如果初始會(huì)話狀態(tài)為 exited，則允許客戶端跳過(guò)它。

did

• String, optional. Distinct ID. 應(yīng)該是設(shè)備或用戶 ID。

系統(tǒng)會(huì)在存儲(chǔ)此 ID 之前自動(dòng)對(duì)其進(jìn)行哈希處理。

seq

• Number, optional. 一個(gè)邏輯時(shí)鐘。默認(rèn)為攝取期間的當(dāng)前 UNIX 時(shí)間戳(以毫秒為單位)。

值 0 是保留的，因?yàn)?init 設(shè)置為 true 的會(huì)話將自動(dòng)將 seq 強(qiáng)制為 0。

timestamp

• String, optional. 會(huì)話更改事件發(fā)生時(shí)的時(shí)間戳。

必須是 ISO 日期時(shí)間字符串。如果未發(fā)送，服務(wù)器將采用當(dāng)前的 UTC 時(shí)間戳。在數(shù)據(jù)模型中，這稱(chēng)為 received。

started

• String, required. 會(huì)話開(kāi)始時(shí)的時(shí)間戳。

必須是 ISO 日期時(shí)間字符串。

init

• Boolean, optional, 默認(rèn)為 false。

如果將其設(shè)置為 true，則表示這是會(huì)話的第一個(gè)事件。這讓服務(wù)器優(yōu)化會(huì)話計(jì)數(shù)，因?yàn)椴恍枰貜?fù)數(shù)據(jù)刪除(客戶端無(wú)論如何都是權(quán)威的)。在內(nèi)部設(shè)置此標(biāo)志時(shí)，處理時(shí) seq 更改為0。

duration

• Number, optional. 一個(gè)可選字段，可以在接收到事件時(shí)傳輸會(huì)話持續(xù)時(shí)間。這可以由客戶端控制，例如，可以減去非活動(dòng)時(shí)間(以浮點(diǎn)數(shù)表示的秒數(shù))。

status

• String, optional, 默認(rèn)是ok。會(huì)話的當(dāng)前狀態(tài)。

一個(gè) session 只能有效地處于兩種狀態(tài)：ok，這意味著會(huì)話處于活動(dòng)狀態(tài)或終止?fàn)顟B(tài)之一。當(dāng)會(huì)話從 ok 移開(kāi)時(shí)，它不能再被更新。

• ok: 會(huì)話當(dāng)前正在進(jìn)行中，但運(yùn)行良好。這可以是會(huì)話的終止?fàn)顟B(tài)。
• exited: 會(huì)話正常終止。
• crashed: 會(huì)話因崩潰而終止。
• abnormal: 會(huì)話遇到非崩潰相關(guān)的異常退出。

errors

• _Number, optional, 默認(rèn)為 0 _。此會(huì)話正在進(jìn)行時(shí)遇到的錯(cuò)誤的運(yùn)行計(jì)數(shù)器。

重要的是，當(dāng)會(huì)話進(jìn)入 crashed 時(shí)，此計(jì)數(shù)器也會(huì)增加。(例如：crash 本身也始終是一個(gè) error)。如果未設(shè)置或?yàn)?0，攝取應(yīng)強(qiáng)制 errors 為 1。

attrs

• Object, required 除了 release 之外的所有 key 都是可選的。具有以下屬性的對(duì)象：
  • release: Sentry Release ID (release)，建議格式為 my-project-name@1.0.0。
  • environment: Sentry 環(huán)境 (environment)。
  • ip_address: 要考慮的主要 IP 地址。這通常是用戶的 IP。此數(shù)據(jù)不會(huì)持久化，而是用于過(guò)濾。如果未設(shè)置，則自動(dòng)填寫(xiě) IP。
  • user_agent: 要考慮的 user agent。這通常是導(dǎo)致會(huì)話的用戶的用戶代理。此數(shù)據(jù)不會(huì)持久化，而是用于過(guò)濾。

Session Aggregates Payload(會(huì)話聚合有效負(fù)載)

特別是對(duì)于 request-mode(請(qǐng)求模式) 會(huì)話(見(jiàn)下文)，通常每秒有數(shù)千個(gè)請(qǐng)求和會(huì)話。

假設(shè)這些 session 將是短時(shí)間的，并且不希望跟蹤它們的持續(xù)時(shí)間， 那么在它們被發(fā)送到 Sentry 之前，可以在 SDK 端將這些 session 聚合在一起。

SDK 應(yīng)聚合關(guān)閉的 session，并按 started 時(shí)間、distinct_id 和 attrs 對(duì)它們進(jìn)行分組。這些組將作為 sessions envelope 項(xiàng)發(fā)送。它包含一個(gè)大致如下所示的 JSON 負(fù)載：

{ 
  "aggregates": [ 
    { 
      "started": "2020-02-07T14:16:00Z", 
      "exited": 123 
    }, 
    { 
      "started": "2020-02-07T14:16:00Z", 
      "did": "optional distinct user id", 
      "exited": 12, 
      "errored": 3 
    } 
  ], 
  "attrs": { 
    "release": "my-project-name@1.0.0", 
    "environment": "development" 
  } 
} 

請(qǐng)注意，這必須包含在 envelope 中。所以完整的 envelope 看起來(lái)像這樣：

{} 
{"type": "sessions"} 
{"aggregates": [...], "attrs": {...}} 

aggregates

• Array, required. 按 started 時(shí)間戳和 distinct id (did) 分組的聚合數(shù)組。
  • started: Required. 組的時(shí)間戳，四舍五入到分鐘。必須是 ISO 日期時(shí)間字符串。
  • did: Optional. 組的 distinct user id。
  • exited: Optional. 狀態(tài)為 "exited" 且沒(méi)有任何錯(cuò)誤的 session 數(shù)。
  • abnormal: Optional. 狀態(tài)為 "abnormal" 的 session 數(shù)。
  • crashed: Optional. 狀態(tài)為 "crashed" 的 session 數(shù)。
  • errored: Optional. 狀態(tài)為 "exited" 且 errors 計(jì)數(shù)不為零的 session 數(shù)。

attrs

• Object, required. 見(jiàn)上文。

崩潰與會(huì)話

會(huì)話(Session)和錯(cuò)誤(error)事件是 Sentry 中兩個(gè)不同的系統(tǒng)。 Session 更新可以在不發(fā)送錯(cuò)誤事件的情況下完成，同樣，可以在沒(méi)有 session 更新的情況下發(fā)送 error。

這使 client 可以完全控制應(yīng)如何執(zhí)行 session 更新。激勵(lì)因素是服務(wù)器可以在某些情況下自由拒絕 error 事件，在這種情況下記錄 session 信息仍然很有趣。例如，如果項(xiàng)目對(duì) error 事件應(yīng)用了 rate limit，則它們的 session 數(shù)據(jù)仍然可以繞過(guò)此 rate limit 路由到項(xiàng)目。

但是，強(qiáng)烈建議在與 crash 事件相同的 envelope 中發(fā)送 session 更新，以防 session 轉(zhuǎn)換到 crashed 狀態(tài)。如果網(wǎng)絡(luò)不可靠，這將確保事件同時(shí)到達(dá)系統(tǒng)。

重要客戶端行為

這些是 client 必須遵守的重要規(guī)則：

屬性不可變性

當(dāng)前不允許 session 更改后續(xù)更新中的任何屬性，包括 did、started 或其他屬性。唯一允許更改的屬性是 session 狀態(tài)、持續(xù)時(shí)間或錯(cuò)誤計(jì)數(shù)。如果一開(kāi)始不知道 user，則應(yīng)該延遲 session 開(kāi)始，或者一旦知道 user 就應(yīng)該重新啟動(dòng) session。

會(huì)話計(jì)數(shù)/初始化

發(fā)送到系統(tǒng)的初始 session 更新必須將 init 設(shè)置為 true。這是必要的，因?yàn)榉?wù)器當(dāng)前不會(huì)將總 session 計(jì)數(shù)作為優(yōu)化進(jìn)行重復(fù)數(shù)據(jù)刪除。如果初始的 init: true flag 丟失，則 Sentry 可能無(wú)法正確攝取 session。

終止會(huì)話狀態(tài)

Session 可以存在兩種狀態(tài)：進(jìn)行中(progress)或終止(terminated)。終止的 session 不得接收進(jìn)一步的更新。退出(exited)、崩潰(crashed)和異常(abnormal)都是終止?fàn)顟B(tài)。當(dāng) session 達(dá)到此狀態(tài)時(shí)，client 不得再報(bào)告任何 session 更新或啟動(dòng)新 session。

鼓勵(lì) SDK 區(qū)分結(jié)束 session 的不同方式：

• exited: 這意味著 session 干凈地結(jié)束了。從成功報(bào)告的角度來(lái)看，這與保持 ok 的 session 沒(méi)有任何不同。但是，只有以 exited 結(jié)尾的 session 才會(huì)被考慮用于 session 持續(xù)時(shí)間。即使發(fā)生 error，session 也可以進(jìn)入 exited 狀態(tài)。
• crashed: 在以下情況下，session 應(yīng)報(bào)告為 crashed：
  • 發(fā)生未處理的錯(cuò)誤(unhandled error)并且 session 自然結(jié)束(例如：HTTP 請(qǐng)求結(jié)束)
  • 應(yīng)用程序完全崩潰(崩潰到桌面，終止)
  • 用戶反饋(feedback)對(duì)話框顯示給用戶。在此之后，SDK 必須啟動(dòng)一個(gè)新 session，就像它完全崩潰一樣。
• abnormal: 如果可以的話，鼓勵(lì) SDK 始終將 session 轉(zhuǎn)換為 exited 或 crashed。對(duì)于能夠始終結(jié)束 session 的 SDK，如果無(wú)法檢測(cè)到應(yīng)用程序正確關(guān)閉， 則應(yīng)以 abnormal 結(jié)束 session。異常 session 示例：

異常的 session 結(jié)束通常會(huì)在應(yīng)用程序重新啟動(dòng)時(shí)被記錄下來(lái)。

• 計(jì)算機(jī)被關(guān)閉/斷電
• 用戶通過(guò) kill -9 或任務(wù)管理器強(qiáng)制關(guān)閉應(yīng)用程序

崩潰、異常與錯(cuò)誤

Session 應(yīng)該在遇到未處理的錯(cuò)誤(例如應(yīng)用程序完全崩潰)時(shí)轉(zhuǎn)換為 crashed。對(duì)于無(wú)法完全崩潰的應(yīng)用程序(例如網(wǎng)站)，如果用戶遇到錯(cuò)誤對(duì)話框，則轉(zhuǎn)換到 crashed 狀態(tài)是可以接受的。對(duì)于我們?yōu)槊總€(gè)傳入請(qǐng)求創(chuàng)建 session 的 server 環(huán)境，crashed 基本上就像狀態(tài)代碼 500 內(nèi)部服務(wù)器錯(cuò)誤。因此，如果在請(qǐng)求期間發(fā)生未處理的錯(cuò)誤(unhandled error)，會(huì)話應(yīng)該 crashed。

Abnormal 是其命運(yùn)未知的 session。例如，對(duì)于桌面應(yīng)用程序，如果 session 被存儲(chǔ)但未觀察到應(yīng)用程序退出但也沒(méi)有崩潰， 則將 session 轉(zhuǎn)換為 abnormal 是有意義的。在這些情況下，用戶通過(guò)任務(wù)管理器強(qiáng)制關(guān)閉應(yīng)用程序、機(jī)器斷電或其他情況?？梢酝ㄟ^(guò)將 session 持久保存到磁盤(pán)來(lái)存儲(chǔ) session。這個(gè)保存的文件可以在應(yīng)用程序重啟時(shí)檢測(cè)到，以關(guān)閉 abnormal 的會(huì)話。

錯(cuò)誤的 session 由大于零的 errors 計(jì)數(shù)器確定。 client 需要對(duì)被視為 error 的事件進(jìn)行計(jì)數(shù)，并將計(jì)數(shù)與 session 更新一起發(fā)送。正常且錯(cuò)誤計(jì)數(shù)大于零的 session 被視為錯(cuò)誤 session。所有崩潰和異常 session 也始終被視為錯(cuò)誤，但會(huì)從最終錯(cuò)誤 session 計(jì)數(shù)中減去。

退出

Session 可以轉(zhuǎn)換為 exited，這與 ok 狀態(tài)完全相同， 但有一個(gè)區(qū)別：轉(zhuǎn)換為 exited 的 session 的 session 持續(xù)時(shí)間是平均的。這讓 Sentry 向您顯示非崩潰 session 的持續(xù)時(shí)間。

警報(bào)

當(dāng) issue 影響到指定百分比的會(huì)話時(shí)觸發(fā)警報(bào)。創(chuàng)建新的 issue alert 并選擇 "When" 條件 An issue affects more than {X} percent of sessions(問(wèn)題影響超過(guò) {X}% 的會(huì)話)。在 Issue Alert Configuration 文檔中查看更多問(wèn)題警報(bào)選項(xiàng)。

• https://docs.sentry.io/product/alerts/alert-types/#issue-alerts
• https://docs.sentry.io/product/alerts/create-alerts/issue-alert-config/

SDK 注意事項(xiàng)

一般來(lái)說(shuō)，SDK 可以使用兩種獨(dú)立的健康報(bào)告模式。一個(gè)是非常短暫的 session，另一個(gè)是用戶參與的 session。

短時(shí)會(huì)話 (server-mode / request-mode)

這些 session 大致對(duì)應(yīng)于服務(wù)器設(shè)置中的 HTTP 請(qǐng)求或 RPC 調(diào)用。

• 海量請(qǐng)求, 通常每個(gè)請(qǐng)求一個(gè)會(huì)話
• Session 數(shù)通常高于 Sentry 事件數(shù)
• Session 附加到單個(gè) hub/concurrency unit
• 計(jì)時(shí)信息通常是無(wú)用的，因?yàn)?session 時(shí)間以毫秒為單位

用戶參與的會(huì)話 (user-mode / application-mode)

這些 session 更對(duì)應(yīng)于實(shí)際的用戶 session 或應(yīng)用程序運(yùn)行。這就是您在 Web 瀏覽器、移動(dòng)世界、命令行應(yīng)用程序或類(lèi)似應(yīng)用程序中會(huì)看到的內(nèi)容。

• 通常只是從應(yīng)用程序開(kāi)始到退出的單個(gè) session
• 如果適用，一旦應(yīng)用程序置于后臺(tái)超過(guò) 30 秒(移動(dòng) SDK)，session 就可以結(jié)束
• session 次數(shù)通常少于 Sentry 事件
• session 跨越多個(gè) hub/thread
• session 持續(xù)時(shí)間通常以分鐘為單位，計(jì)時(shí)信息很有用

從 API 的角度來(lái)看，這兩種情況看起來(lái)很相似，但對(duì)于 SDK 的建議不同。

選擇會(huì)話模式

雖然理論上可以在單個(gè)應(yīng)用程序中使用兩種會(huì)話模式，但建議 SDK 默認(rèn)使用最適合語(yǔ)言生態(tài)系統(tǒng)主要用例的單一模式。這類(lèi)似于某些 SDK 支持的全局 Hub 模式，并且可以以相同的方式使用。

當(dāng) SDK 配置為使用 user-mode 會(huì)話或全局 Hub 模式時(shí)，應(yīng)在應(yīng)用程序啟動(dòng)時(shí)啟動(dòng)單個(gè)會(huì)話，并應(yīng)在應(yīng)用程序的運(yùn)行時(shí)持續(xù)存在。根據(jù) SDK 內(nèi)部結(jié)構(gòu)，此單個(gè) session 可以在所有應(yīng)用程序線程和線程本地 Hub 之間共享。

使用 server-mode 會(huì)話時(shí)，不會(huì)啟動(dòng)應(yīng)用程序范圍的 session， 并且由集成或用戶在收到請(qǐng)求時(shí)啟動(dòng) session 并在返回響應(yīng)時(shí)結(jié)束 session。

統(tǒng)一 API 的含義

SDK 應(yīng)該遵循的統(tǒng)一 API 定義了 Hub、Scope 和 Client 的概念。

從概念上講，session 是 Hub 的關(guān)注點(diǎn)，與 scope 不同，session 不應(yīng)嵌套。當(dāng)任何一種事件發(fā)生時(shí)，應(yīng)該只有一個(gè)明確的 session 來(lái)跟蹤錯(cuò)誤計(jì)數(shù)。

在考慮通過(guò) SDK 的事件流時(shí)，從靜態(tài) capture_event 函數(shù)，通過(guò)線程本地 Hub，進(jìn)入 Client::capture_event(event, scope) 方法;根據(jù) SDK 的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)，將 session 附加到 Scope 可能是有意義的， 這將使 Client 可以將 event 和 session 更新捆綁到單個(gè) envelope 中以發(fā)送到 Sentry。

會(huì)話更新以及何時(shí)向上游發(fā)送更新

對(duì)于所有 SDK，只要在調(diào)用 apply_to_scope 的類(lèi)似位置捕獲數(shù)據(jù)以增加 error 計(jì)數(shù)， 或根據(jù) distinct ID / user ID 更新 session，將自動(dòng)更新當(dāng)前 session。

SDK 通常應(yīng)旨在減少向上游發(fā)送的 envelope 數(shù)量。

跟蹤大量會(huì)話的 server-mode SDK 應(yīng)考慮使用定期 session 刷新器(每 60 秒)， 將會(huì)話預(yù)聚合到單個(gè) session_aggregates envelope 項(xiàng)中。

User-Mode SDK 可能會(huì)選擇在同一 envelope 中發(fā)送 session 更新以及捕獲的事件。關(guān)閉 session 的最終 session 更新可以類(lèi)似于 Server-Mode session 進(jìn)行批處理。

在任何一種情況下，必須為 session 的第一次傳輸正確設(shè)置 init 標(biāo)志， 并且 session 元數(shù)據(jù)(例如 distinct ID)在初始傳輸后必須是不可變的。

會(huì)話的預(yù)聚合

如果 SDK 配置為使用 server-mode session，則應(yīng)在將 session 計(jì)數(shù)發(fā)送到 Sentry 之前對(duì)其進(jìn)行分組和預(yù)聚合。每當(dāng) session 關(guān)閉(轉(zhuǎn)換到 terminal 狀態(tài))，并且之前沒(méi)有向上游發(fā)送(其 init 標(biāo)志為 true)時(shí)，它就有資格進(jìn)行聚合，其執(zhí)行方式如下：

• Session 的 started 時(shí)間戳應(yīng)四舍五入到分鐘。
• 然后必須將 Session 聚合到由該舍入時(shí)間戳標(biāo)識(shí)的存儲(chǔ) bucket 中，以及會(huì)話的 distinct id (did)。
• 在適當(dāng)?shù)?bucket 中，根據(jù) session 狀態(tài)增加 session 計(jì)數(shù)。與單個(gè) session 更新相反，"errored" 狀態(tài)用于標(biāo)記具有 "exited" 狀態(tài)和非零 errors 計(jì)數(shù)的會(huì)話。

公開(kāi) API

公開(kāi)的最基本的 API 位于 hub 級(jí)別，可讓您啟動(dòng)和停止 session 記錄：

API:

Hub.start_session()

在當(dāng)前 scope 上存儲(chǔ)一個(gè) session 并開(kāi)始跟蹤它。這通常會(huì)將一個(gè)全新的 session 附加到 scope，并隱式地結(jié)束任何已經(jīng)存在的 session。

Hub.end_session()

結(jié)束 session，設(shè)置適當(dāng)?shù)?status 和 duration，并將其加入隊(duì)列以發(fā)送到 Sentry。

Hub.start_auto_session_tracking() / Hub.stop_auto_session_tracking()

停止并重新激活自動(dòng) session 跟蹤。

初始化選項(xiàng)：

auto_session_tracking

這通過(guò)集成 啟用/禁用 自動(dòng) session 跟蹤。

SDK 實(shí)現(xiàn)指南

在開(kāi)始在 SDK 中實(shí)現(xiàn)此功能之前，請(qǐng)與團(tuán)隊(duì)聯(lián)系。

• https://github.com/getsentry/develop/pull/323

我們通過(guò)從 SDK 發(fā)送 session 有效負(fù)載來(lái)跟蹤 Sentry 中每個(gè)項(xiàng)目 release 的健康狀況。 Session 有效負(fù)載提供諸如 session 持續(xù)時(shí)間以及是否存在錯(cuò)誤/崩潰等數(shù)據(jù)。

SDK 以兩種模式之一跟蹤 session：

• 單個(gè) Session
• Session 聚合

單個(gè) session 是一般情況，非常適合通常只涉及單個(gè)用戶的(相對(duì)短暫的)應(yīng)用程序。例子：

• 命令行實(shí)用程序，如 craft;craft 子命令的每次執(zhí)行都會(huì)向 Sentry 報(bào)告一個(gè) session
• 用戶與 mobile app 交互
• 用戶使用他們最喜歡的瀏覽器加載網(wǎng)站

當(dāng)發(fā)送單個(gè) session 不受歡迎或不切實(shí)際時(shí)，將使用 session 聚合。為了限制資源使用(即內(nèi)存和網(wǎng)絡(luò))，SDK 會(huì)跟蹤有關(guān)最近發(fā)生的一批會(huì)話的摘要信息， 實(shí)際上不必處理代表構(gòu)成聚合的各個(gè) session 的 session 對(duì)象。此模式適用于運(yùn)行任意長(zhǎng)時(shí)間并為潛在的多個(gè)用戶處理更大吞吐量的應(yīng)用程序，例如 Web Server、后臺(tái) Job Worker 等。請(qǐng)注意，對(duì)于這些類(lèi)型的應(yīng)用程序，session 的更好定義與執(zhí)行匹配單個(gè) HTTP 請(qǐng)求或任務(wù)，而不是整個(gè)應(yīng)用程序進(jìn)程的單個(gè)執(zhí)行。

在任何一種情況下，SDK 都應(yīng)默認(rèn)創(chuàng)建和報(bào)告 session，根據(jù)應(yīng)用程序類(lèi)型選擇單獨(dú)報(bào)告或作為聚合報(bào)告。

如果 SDK 可以檢測(cè)到 session 聚合更好地為應(yīng)用程序提供服務(wù)，則它不得報(bào)告應(yīng)用程序范圍的 session。應(yīng)用程序范圍的 session 可能仍會(huì)在 SDK 初始化期間創(chuàng)建，但必須中止并且永遠(yuǎn)不會(huì)發(fā)送到 Sentry。例如，在 Node.js SDK 中，如果應(yīng)用程序使用提供的 requestHandler 集成，我們可以檢測(cè)到它可能是一個(gè) web server。

單個(gè)會(huì)話功能

配置

• 全局/靜態(tài) API 默認(rèn)開(kāi)啟;

如果用戶不想跟蹤 session，他們應(yīng)該能夠禁用 session。

報(bào)告 session 和確定 Sentry 中項(xiàng)目的 Release Health 的先決條件，例如 release 應(yīng)由 SDK 自動(dòng)檢測(cè)，例如通過(guò)查找 env 變量。

(也許，需要討論)如果我的先決條件不能被檢測(cè)到(例如，沒(méi)有好的方法來(lái)確定 release 版本)， 那么我們?cè)O(shè)置一些默認(rèn)值，以便我們總是可以默認(rèn)報(bào)告 session (取決于討論，這可能不會(huì)是 SDK 代碼的更改，但在 Relay 中，基本上刪除了 session 有效負(fù)載中的硬要求)。

會(huì)話的生命周期

默認(rèn)情況下，會(huì)話應(yīng)該只為由 Sentry.init 初始化的全局 hub/client 啟用，并默認(rèn)為任何其他手動(dòng)創(chuàng)建的 client 禁用。 Session 在 SDK 初始化時(shí)開(kāi)始(理想情況下，當(dāng)默認(rèn) client 綁定到全局 hub 時(shí))并在以下情況之一發(fā)生時(shí)結(jié)束：顯式調(diào)用 Hub.endSession() 方法;或程序無(wú)錯(cuò)誤終止;或程序以未處理的異常終止;或程序以未處理的 promise rejection 而終止。

必須注意永遠(yuǎn)不要嘗試為已經(jīng)結(jié)束的 session 向 Sentry 發(fā)送新的 session 負(fù)載。例如，如果用戶使用 Hub.endSession() 手動(dòng)結(jié)束 session，則程序終止時(shí)不應(yīng)有任何新的 session 更新。

會(huì)話屬性和可變性

向 Sentry 發(fā)送會(huì)話

Session 最初在一定的(最初是硬編碼的，配置越少越好)延遲(大約 1 到 30 秒 TBD)后發(fā)送， 然后在程序終止時(shí)更新持續(xù)時(shí)間、最終狀態(tài)和錯(cuò)誤計(jì)數(shù)。請(qǐng)注意，作為一種優(yōu)化，short lived 程序不會(huì)向 Relay 發(fā)送 2 個(gè) session 請(qǐng)求， 而只會(huì)向 Relay 發(fā)送最后一個(gè)帶有狀態(tài)和持續(xù)時(shí)間的請(qǐng)求。

會(huì)話聚合功能

配置

默認(rèn)情況下應(yīng)啟用 session，session 在 web server 收到請(qǐng)求后立即啟動(dòng)，并在響應(yīng)完全發(fā)回后立即結(jié)束。

會(huì)話的生命周期

 

Session 從不被跟蹤或單獨(dú)發(fā)送，相反，它們被聚合，聚合每 30 秒發(fā)送一次，最后一次當(dāng) web server 終止。作為對(duì)上述點(diǎn)的實(shí)現(xiàn)提示，當(dāng) "Client" 關(guān)閉或刷新時(shí)，相關(guān)聯(lián)的 "Session Flusher" 也應(yīng)被刷新并在傳輸被刷新/關(guān)閉之前提交當(dāng)前聚合。確保這對(duì)于 Serverless 來(lái)說(shuō)是合理的 — 我們不會(huì)使用 "request mode" 和 SessionFlusher，因?yàn)槲覀儾荒茉?request-response 流之外進(jìn)行任何工作。提供一種與現(xiàn)有 Node 框架(Express、Next.js、Koa)集成的簡(jiǎn)單方法。