• モニタリング
• 良いイベントドロップ
  • 症状
  • 問題の特定
  • GitLabアプリケーション層のトラブルシューティング
  • AWSレイヤーのトラブルシューティング
  • データウェアハウス層のトラブルシューティング
• 除雪車エンリッチャーの遅れ
  • オンコールのSREにお問い合わせください

除雪機のトラブルシューティング

モニタリング

このページでは、多くの内部ツールからのダッシュボードとアラートについて説明します。

Snowplowの使用状況を監視するためのツールの概要については、こちらの内部ビデオをご覧ください（閲覧にはGitLab Unfilteredへのログインが必要です）。

良いイベントドロップ

症状

Sisense アラートが #g_product_intelligence Slack チャンネルに送信されます。

問題の特定

まず、Snowplowのデータパイプラインのどのステージでドロップが発生しているかを特定する必要があります。CloudWatchのSnowplowダッシュボードから始めます。CloudWatchにアクセスできない場合は、GitLabのチームメンバーがこれに似たアクセスリクエストのイシューを作成することができます:https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues/9730 。CloudWatchダッシュボードの時間範囲を過去4週間に設定します。次のChartをご覧ください：

1. ELB New Flow Count Collector Auto Scaling Group Network In/Out ロードバランサーを経由したコレクターへの接続数とコレクターによって処理されたデータ量（バイト単位）が表示されます。もしそこにドロップが見えるなら、GitLabアプリケーションから発生したイベントが少ないことを意味します。詳細はアプリケーションレイヤーガイドへ
2. Firehose Records to S3 - イベントレコードが S3 バケットに保存された数を示しています。このチャートでドロップがあり、1.からのチャートでドロップがない場合は、問題が AWSインフラレイヤーにあることを意味します。
3. もし、1.から3.のどのチャートにもドロップが見られなかった場合、それはデータウェアハウスレイヤーに問題があることを意味しますので、データウェアハウスレイヤーガイドを参照してください。

GitLabアプリケーション層のトラブルシューティング

アプリケーションレイヤーで発生するドロップは何らかのイシューの症状である可能性がありますが、典型的なアプリケーションのライフサイクルの結果であったり、アナリティクスのインストルメンテーションや実験のトラッキングに行われた意図的な変更の結果であったり、あるいはユーザー数の多い世界の一部の地域での公開休日の結果である可能性もあります。解決すべき根本的な問題があるかどうかを確認するには、以下のことをチェックしてください：

1. Googleアナリティクスで about.gitlab.com ウェブサイトのトラフィックをチェックし、祝日がGitLabシステムの利用全体に影響を与えるかどうかを確認します。
   1. Googleアナリティクスへのアクセスには、まずアクセスリクエスト（例：アクセスリクエスト内部イシュー）を開く必要があるかもしれません。
2. SiSense でselect date(dvce_created_tstamp) , event , count(*) from legacy.snowplow_unnested_events_90 where dvce_created_tstamp > '2021-06-15' and dvce_created_tstamp < '2021-07-10' group by 1 , 2 order by 1 , 2 をプロットし、どのようなイベントがドロップの原因であったかを確認します。
3. プロットselect date(dvce_created_tstamp) ,se_category , count(*) from legacy.snowplow_unnested_events_90 where dvce_created_tstamp > '2021-06-15' and dvce_created_tstamp < '2021-07-31' and event = 'struct' group by 1 , 2 order by 1, 2 疑われるカテゴリーで最大の低下を記録したイベントは何か
4. 報告されたイベントの減少の原因となるようなマージされたMRがあるかどうかをチェックし、~"analytics instrumentation "と~"growth experiment "のラベルが付いたMRに注目します。
5. (Grafanaのexploreタブで) 以下のPrometheusカウンターgitlab_snowplow_events_total 、gitlab_snowplow_failed_events_total 、gitlab_snowplow_successful_events_total をチェックして、GitLab.comから正しく発生したイベントの数を確認します。sum(rate(gitlab_snowplow_successful_events_total{env="gprd"}[5m])) / sum(rate(gitlab_snowplow_events_total{env="gprd"}[5m])) を使用するクエリの例では、送信されたイベントの総数と比較して、良いイベントの数が増加した割合をグラフ化します。もし数が1から減少したら、それはGitLabとAWSコレクターフリート間の通信に問題があるかもしれないことを意味します。
6. Kibana でログを確認し、失敗したイベントが記録されている場合は{ "query": { "match_phrase": { "json.message": "failed to be reported to collector at" } } } でフィルタリングします。

除雪車のイベント量が予想外に減少したため、調査を実施しました。

GitLabチームメンバーはこの極秘イシューで詳細をご覧いただけます：https://gitlab.com/gitlab-org/gitlab/-/issues/335206

AWSレイヤーのトラブルシューティング

既に実施済みの調査

• Snowplow のページビューが激減
• snowplow.trx.gitlab.net 到達不能

データウェアハウス層のトラブルシューティング

データチームに連絡して、データウェアハウスの現状を尋ねてください。ハンドブックのページに連絡先の詳細が記載されています。

除雪車エンリッチャーの遅れ

Snowplow Raw Good Stream Backing Upのアラートがある場合、私たちは電子メール通知を受け取ります。これは、Snowplow EnrichersがSnowplowイベントの量に対して十分にスケールしていないために起こることがあります。

遅延が48時間を超えると、データが失われます。

オンコールのSREにお問い合わせください

以下のテンプレートを使用して、#infrastructure_loungeSlack チャンネルにメッセージを送信してください：

Hello team!

We received an alert for [Snowplow Raw Good Stream Backing Up](https://us-east-1.console.aws.amazon.com/cloudwatch/home?region=us-east-1#alarmsV2:alarm/SnowPlow+Raw+Good+Stream+Backing+Up?).

Enrichers are not scalling well for the amount of events we receive.

See the [dashboard](https://us-east-1.console.aws.amazon.com/cloudwatch/home?region=us-east-1#dashboards:name=SnowPlow).

Could we get assistance to fix the delay?

Thank you!