Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15,664 changes: 8,012 additions & 7,652 deletions gt-lock.json

Large diffs are not rendered by default.

Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,12 @@ ClickHouse サーバーに接続することなく、プログラミング言語

**新機能!** DataStore は、おなじみの pandas 構文と ClickHouse のパフォーマンスを組み合わせた、pandas 互換の API を提供します。

:::tip Hex で始める

* 📖 <a href="https://app.hex.tech/partnerships/app/chDB-Tutorial-032XsQ4qoKtlXxcw49joav/latest" target="_blank"><b>入門チュートリアル</b></a> — 最初の接続をセットアップする
* 🚀 <a href="https://app.hex.tech/signup/clickhouse-30" target="_blank"><b>Hex 30日間延長トライアル</b></a> — ClickHouse インテグレーションへのフルアクセス
:::

### 1行でのマイグレーション \{#one-line-migration\}

```python
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -109,13 +109,13 @@ Basic ティアのサービスは、高速リリースチャネルの直後に
- より低速なチャネルへ移行してもサービスがダウングレードされることはなく、そのチャネルで新しいバージョンが利用可能になるまで現在のバージョンのまま維持されます(例: 通常からスロー、高速から通常またはスロー)。
:::

## 予定されたアップグレード \{#scheduled-upgrades\}
## スケジュール済みアップグレード \{#scheduled-upgrades\}

<EnterprisePlanFeatureBadge feature="Scheduled upgrades" linking_verb_are="true"/>

Enterprise ティアのサービスに対して、アップグレードの実行時間帯を設定できます。

アップグレードスケジュールを指定したいサービスを選択し、左側メニューから `Settings` を選択します。`Scheduled upgrades` セクションまでスクロールします
アップグレードスケジュールを指定したいサービスを選択し、左側メニューから `Settings` を選択します。`Scheduled upgrades` までスクロールします

<div class="eighty-percent">
<Image img={scheduled_upgrades} size="lg" alt="Scheduled upgrades" border/>
Expand All @@ -132,5 +132,5 @@ Enterprise ティアのサービスに対して、アップグレードの実行
<br/>

:::note
予定されたアップグレードは定義されたスケジュールに従って実行されますが、重要なセキュリティパッチや脆弱性修正については例外が適用されます。緊急性の高いセキュリティ問題が特定された場合は、予定された時間帯以外でアップグレードが実施されることがあります。そのような例外が発生する場合は、必要に応じてお客様に通知されます。
スケジュール済みアップグレードは定義されたスケジュールに従って実行されますが、重要なセキュリティパッチや脆弱性修正に加え、データ破損やデータ損失につながる可能性があるシナリオについては例外が適用されます。緊急性の高いセキュリティ問題が特定された場合は、スケジュールされた時間帯以外でアップグレードが実施されることがあります。そのような例外が発生する場合は、必要に応じてお客様に通知されます。
:::
Original file line number Diff line number Diff line change
Expand Up @@ -157,19 +157,20 @@ node2 :) SELECT materialize(hostName()) AS host, groupArray(n) FROM r.d GROUP BY

サポートされている設定は次のとおりです:

| Setting | Default | Description |
| ---------------------------------------------------------------------------- | ------------------------------ | ----------------------------------------------------------------------------------------- |
| `max_broken_tables_ratio` | 1 | 停止状態(stale)のテーブル数と全テーブル数の比率がこの値より大きい場合、レプリカを自動復旧しない |
| `max_replication_lag_to_enqueue` | 50 | レプリケーション遅延がこの値より大きい場合、レプリカはクエリを実行しようとすると例外をスローする |
| `wait_entry_commited_timeout_sec` | 3600 | タイムアウトを超過した場合、イニシエータホストがまだそのクエリを実行していなければ、レプリカはそのクエリのキャンセルを試みる |
| `collection_name` | | クラスタ認証に関するすべての情報が定義されている、サーバー設定内のコレクションの名前 |
| `check_consistency` | true | ローカルメタデータと Keeper 内のメタデータの整合性をチェックし、不整合がある場合はレプリカの復旧を行う |
| `max_retries_before_automatic_recovery` | 10 | レプリカを失われたものとしてマークしスナップショットから復旧する前に、キューエントリの実行を試行する最大回数(0 は無制限を意味する) |
| `allow_skipping_old_temporary_tables_ddls_of_refreshable_materialized_views` | false | 有効にすると、Replicated データベースで DDL を処理する際、可能な場合はリフレッシュ可能なマテリアライズドビューの一時テーブルの DDL の作成と交換をスキップする |
| `logs_to_keep` | 1000 | Replicated データベースに対して ZooKeeper に保持するログのデフォルト件数。 |
| `default_replica_path` | `/clickhouse/databases/{uuid}` | ZooKeeper におけるデータベースへのパス。データベース作成時に引数が省略された場合に使用される。 |
| `default_replica_shard_name` | `{shard}` | データベース内のレプリカのシャード名。データベース作成時に引数が省略された場合に使用される。 |
| `default_replica_name` | `{replica}` | データベース内のレプリカ名。データベース作成時に引数が省略された場合に使用される。 |
| Setting | Default | Description |
| ---------------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `max_broken_tables_ratio` | 1 | 停止状態 (stale) のテーブル数と全テーブル数の比率がこの値より大きい場合、レプリカを自動復旧しない |
| `max_replication_lag_to_enqueue` | 50 | レプリケーション遅延がこの値より大きい場合、レプリカはクエリを実行しようとすると例外をスローする |
| `wait_entry_commited_timeout_sec` | 3600 | タイムアウトを超過した場合、イニシエータホストがまだそのクエリを実行していなければ、レプリカはそのクエリのキャンセルを試みる |
| `collection_name` | | クラスタ認証に関するすべての情報が定義されている、サーバー設定内のコレクションの名前 |
| `check_consistency` | true | ローカルメタデータと Keeper 内のメタデータの整合性をチェックし、不整合がある場合はレプリカの復旧を行う |
| `max_retries_before_automatic_recovery` | 10 | レプリカを失われたものとしてマークしスナップショットから復旧する前に、キューエントリの実行を試行する最大回数 (0 は無制限を意味する) |
| `allow_skipping_old_temporary_tables_ddls_of_refreshable_materialized_views` | false | 有効にすると、Replicated データベースで DDL を処理する際、可能な場合はリフレッシュ可能なマテリアライズドビューの一時テーブルの DDL の作成と交換をスキップする |
| `logs_to_keep` | 1000 | Replicated データベースに対して ZooKeeper に保持するログのデフォルト件数。 |
| `default_replica_path` | `/clickhouse/databases/{uuid}` | ZooKeeper におけるデータベースへのパス。データベース作成時に引数が省略された場合に使用される。 |
| `default_replica_shard_name` | `{shard}` | データベース内のレプリカのシャード名。データベース作成時に引数が省略された場合に使用される。 |
| `default_replica_name` | `{replica}` | データベース内のレプリカ名。データベース作成時に引数が省略された場合に使用される。 |
| `internal_replication` | false | この Replicated データベースのクラスタを使用して作成された分散テーブルが、いずれか 1 つのレプリカにデータを送信するか (内部レプリケーションは、クラスタ内のレプリカが自律的にレプリケーションを行うことを意味する) 、またはすべてのレプリカに送信するか (内部レプリケーションなしは、分散テーブルが挿入されたデータをすべてのレプリカに送信することを意味する) |

デフォルト値は設定ファイルで上書きできます。

Expand All @@ -185,6 +186,7 @@ node2 :) SELECT materialize(hostName()) AS host, groupArray(n) FROM r.d GROUP BY
<default_replica_path>/clickhouse/databases/{uuid}</default_replica_path>
<default_replica_shard_name>{shard}</default_replica_shard_name>
<default_replica_name>{replica}</default_replica_name>
<internal_replication>false</internal_replication>
</database_replicated>
</clickhouse>
```
Original file line number Diff line number Diff line change
Expand Up @@ -244,8 +244,6 @@ SELECT count() FROM cloudflare_http_logs;

## 次のステップ \{#next-steps\}

Cloudflare のログが ClickStack に取り込まれるようになったら、次の作業を行います。

* セキュリティイベント (WAF によるブロック、ボットトラフィックの急増、エラー率のしきい値) に対する[アラート](/use-cases/observability/clickstack/alerts)を設定します
* データ量に応じて[データ保持ポリシー](/use-cases/observability/clickstack/ttl)を最適化します
* 特定のユースケース (API パフォーマンス、キャッシュ最適化、地域別トラフィック分析) 向けに追加のダッシュボードを作成します
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -24,17 +24,7 @@ import { TrackedLink } from '@site/src/components/GalaxyTrackedLink/GalaxyTracke
# ClickStack を使用した AWS CloudWatch Logs の監視 \{#cloudwatch-clickstack\}

:::note[要点まとめ]
このガイドでは、OpenTelemetry Collector の AWS CloudWatch receiver を使用して、AWS CloudWatch のログを ClickStack に転送する方法を説明します。次の内容を学びます:

- OpenTelemetry Collector を構成して CloudWatch からログを取得する
- AWS の認証情報および IAM 権限を設定する
- OTLP 経由で CloudWatch Logs を ClickStack に送信する
- ロググループのフィルタリングと自動検出を行う
- 事前構築済みのダッシュボードを使用して CloudWatch ログパターンを可視化する

本番の AWS 環境を設定する前に統合をテストしたい場合のために、サンプルログを含むデモデータセットを利用できます。

所要時間の目安: 10〜15 分
OpenTelemetry Collector の CloudWatch receiver を使用して、AWS CloudWatch のログを ClickStack に転送します。名前付きロググループと自動検出に対応しています。デモ用データセットと事前構築済みのダッシュボードが含まれます。
:::

## 概要 \{#overview\}
Expand Down Expand Up @@ -487,13 +477,11 @@ groups:
limit: 50 # Reduce from 100 to 50
```

## 次のステップ {#next-steps}

CloudWatch のログが ClickStack に流れ込むようになったら、次のステップとして以下を検討してください。
## 次のステップ

- 重大なイベント接続失敗、エラー急増に対する[アラート](/use-cases/observability/clickstack/alerts)を設定する
- ログが ClickStack にあるので、保持期間の調整や S3 へのアーカイブによって CloudWatch コストを削減する
- 収集設定から除外することでノイズの多いロググループをフィルタリングし、インジェスト量を削減する
* 重大なイベント (接続失敗、エラー急増) に対する[アラート](/use-cases/observability/clickstack/alerts)を設定する
* ログが ClickStack にあるので、保持期間の調整や S3 へのアーカイブによって CloudWatch コストを削減する
* 収集設定から除外することでノイズの多いロググループをフィルタリングし、インジェスト量を削減する

## 本番環境への移行 {#going-to-production}

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -25,17 +25,8 @@ import TabItem from '@theme/TabItem';

# ClickStack を使用した EC2 ホストログの監視 \{#ec2-host-logs-clickstack\}

:::note[要約]
EC2 インスタンスに OpenTelemetry Collector をインストールして、ClickStack で EC2 システムログを監視します。Collector はログに、インスタンス ID、リージョン、アベイラビリティーゾーン、インスタンスタイプといった EC2 メタデータを自動的に付与します。このガイドでは次の内容を学びます:

- EC2 インスタンス上に OpenTelemetry Collector をインストールおよび設定する方法
- EC2 メタデータでログを自動的に付与する方法
- OTLP 経由で ClickStack にログを送信する方法
- あらかじめ用意されたダッシュボードを使用して、クラウドコンテキスト付きで EC2 ホストログを可視化する方法

テスト用として、サンプルログとシミュレートされた EC2 メタデータを含むデモデータセットを利用できます。

所要時間: 10〜15 分
:::note[TL;DR]
インスタンス ID、リージョン、AZ、インスタンスタイプなどの EC2 メタデータを自動付加する OpenTelemetry コレクターを使用して、ClickStack で EC2 システムログを収集・可視化します。デモ用データセットと事前構築済みダッシュボードが含まれます。
:::

## 既存の EC2 インスタンスとの統合 \{#existing-ec2\}
Expand Down Expand Up @@ -586,11 +577,13 @@ sudo journalctl -u otelcol-contrib -n 50
* ログファイルを読み取る際の権限の問題


## 次のステップ {#next-steps}
## 次のステップ

* 重要なシステムイベント (サービス障害、認証失敗、ディスク警告) 向けの[アラート](/use-cases/observability/clickstack/alerts)を設定する
* EC2 メタデータ属性 (リージョン、インスタンスタイプ、インスタンス ID) でフィルタリングして特定のリソースを監視する
* 包括的なトラブルシューティングのために EC2 ホストログをアプリケーションログと相関付ける
* セキュリティ監視 (SSH アクセス試行、sudo 使用状況、ファイアウォールブロック) 向けのカスタムダッシュボードを作成する

EC2 ホストログの監視を設定したら、次の作業を行います。
## 本番環境への移行 {#going-to-production}

- 重要なシステムイベント(サービス障害、認証失敗、ディスク警告)向けの[アラート](/use-cases/observability/clickstack/alerts)を設定する
- EC2 メタデータ属性(リージョン、インスタンスタイプ、インスタンス ID)でフィルタリングして特定のリソースを監視する
- 包括的なトラブルシューティングのために EC2 ホストログをアプリケーションログと相関付ける
- セキュリティ監視(SSH アクセス試行、sudo 使用状況、ファイアウォールブロック)向けのカスタムダッシュボードを作成する
このガイドでは、ホストレベルの監視における本番環境向けの推奨パターンとして、OpenTelemetry コレクターを EC2 インスタンスに直接インストールします。多数のインスタンスにまたがるコレクターの管理には、構成管理ツール (Ansible、Chef、Puppet) や、Kubernetes 環境では OpenTelemetry Operator の利用を検討してください。本番環境向けの設定については、[OpenTelemetry データの送信](/use-cases/observability/clickstack/ingesting-data/opentelemetry) を参照してください。
Loading
Loading