監視とは？メトリクス・ログ・トレースでシステムを見る

監視とは

監視とは、アプリやサーバーが正常に動いているかを継続的に確認することです。エラーが増えていないか、レスポンスが遅くなっていないか、CPUやメモリが限界に近づいていないかを見ます。

初心者は、監視を「サービスの健康診断」と考えると理解しやすいです。

たとえば、Webサービスでは次のようなものを確認します。

• サイトが表示できるか
• APIのエラーが増えていないか
• レスポンスが遅くなっていないか
• サーバーのCPUやメモリが高すぎないか
• データベース接続に失敗していないか

障害が起きてから気づくのではなく、早く気づいて原因を調べるために監視を入れます。

オブザーバビリティとは

オブザーバビリティ（可観測性）は、システムの外部出力からシステム内部の状態を理解する能力です。「何が起きているか」だけでなく「なぜ起きているか」を把握できます。

監視との違い: 監視は既知の問題を検出しますが、オブザーバビリティは未知の問題も調査できます。

3本柱

flowchart LR
 subgraph Observability["オブザーバビリティ"]
 Metrics["メトリクス<br/>Metrics<br/>「何が起きているか」"]
 Logs["ログ<br/>Logs<br/>「詳細は何か」"]
 Traces["トレース<br/>Traces<br/>「どう流れたか」"]
 end

メトリクス（Metrics）

数値データを時系列で記録します。

メトリクスの種類

Prometheusの例

const prometheus = require('prom-client');

// Counterの例
const requestCounter = new prometheus.Counter({
 name: 'http_requests_total',
 help: 'Total HTTP requests',
 labelNames: ['method', 'path', 'status']
});

// Histogramの例
const responseTime = new prometheus.Histogram({
 name: 'http_response_time_seconds',
 help: 'HTTP response time in seconds',
 buckets: [0.1, 0.5, 1, 2, 5]
});

// 計測
app.use((req, res, next) => {
 const end = responseTime.startTimer();
 res.on('finish', () => {
 requestCounter.inc({
 method: req.method,
 path: req.path,
 status: res.statusCode
 });
 end();
 });
 next();
});

重要なメトリクス（RED/USE）

REDメソッド（サービス向け）:

• Rate: リクエストレート
• Errors: エラーレート
• Duration: レスポンスタイム

USEメソッド（リソース向け）:

• Utilization: 使用率
• Saturation: 飽和度
• Errors: エラー

ログ（Logs）

イベントの詳細を記録します。

構造化ログ

// 構造化されていないログ（検索しにくい）
console.log(`User ${userId} logged in from ${ip}`);

// 構造化ログ（検索・分析しやすい）
const log = {
 timestamp: new Date().toISOString(),
 level: 'info',
 message: 'User logged in',
 userId: '123',
 ip: '192.168.1.1',
 userAgent: 'Mozilla/5.0...',
 requestId: 'req_abc123'
};
console.log(JSON.stringify(log));

ログレベル

ログ管理スタック

ELK Stack: アプリ → Filebeat → Logstash → Elasticsearch → Kibana

Loki Stack: アプリ → Promtail → Loki → Grafana

トレース（Traces）

リクエストがシステムを通過する経路を追跡します。

分散トレーシング

flowchart TB
 subgraph Trace["Trace ID: abc123"]
 subgraph Gateway["Span: API Gateway (50ms)"]
 Auth["Span: Auth Service (10ms)"]
 subgraph UserSvc["Span: User Service (30ms)"]
 DB["Span: Database Query (15ms)"]
 end
 end
 end

OpenTelemetryの例

const { trace } = require('@opentelemetry/api');

const tracer = trace.getTracer('my-service');

async function processOrder(orderId) {
 return tracer.startActiveSpan('processOrder', async (span) => {
 span.setAttribute('order.id', orderId);

 try {
 await validateOrder(orderId);
 await processPayment(orderId);
 span.setStatus({ code: 1 }); // OK
 } catch (error) {
 span.setStatus({ code: 2, message: error.message }); // ERROR
 throw error;
 } finally {
 span.end();
 }
 });
}

主要なツール

アラート

メトリクスに基づいて通知を行います。

アラートの設計

# Prometheus Alertmanager の例
groups:
 - name: app-alerts
 rules:
 - alert: HighErrorRate
 expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.1
 for: 5m
 labels:
 severity: critical
 annotations:
 summary: "High error rate detected"
 description: "Error rate is {{ $value }} for the last 5 minutes"

 - alert: SlowResponseTime
 expr: histogram_quantile(0.95, rate(http_response_time_seconds_bucket[5m])) > 2
 for: 10m
 labels:
 severity: warning

アラート疲れの防止

良いアラートの条件:

• ✓ アクションが必要な事象のみ
• ✓ 適切な閾値（ノイズを減らす）
• ✓ 明確な対応手順
• ✓ エスカレーションポリシー

避けるべきアラート:

• ✗ 情報提供のみ（ダッシュボードで確認）
• ✗ すぐに自動復旧する事象
• ✗ 対応できない深夜のアラート

ダッシュボード

Grafanaダッシュボードの構成

まとめ

オブザーバビリティは、複雑なシステムの健全性を理解するために不可欠です。メトリクス、ログ、トレースの3本柱を組み合わせ、問題の検出から原因調査までをスムーズに行えるようにしましょう。適切なアラート設定とダッシュボードにより、障害への迅速な対応が可能になります。

参考リソース

• OpenTelemetry Documentation
• Prometheus Documentation
• Grafana Documentation
• Google SRE Book - Monitoring Distributed Systems
• Google SRE Workbook - Alerting on SLOs

×

PR

×

PR