健康、アップグレード、監査

システムの健康状態を確認し、アップグレードのためのメンテナンスワークフローを追い、監査記録やユーザーフィードバックを使って問題を調査します。

システム健全性と指数の再構築

健康分野

このページではAPI、データベース、Redis、ローカルログイン保護、認証メール、文書解析、検索とインデックス作成、任意の再ランク付け、ランナー、ワークスペースアクセス、権威あるランニングスロット、実際の実行ターン、リカバリー、子プロセス数、並行性制限を報告します。 Dockerのデプロイでは、API、Runner、ワーカー、Web、ゲートウェイ、PostgreSQL、Redis、その他の観察されたコンテナのCPU、メモリ、PID、状態も報告します。

そこには、認証情報、接続文字列、Redisキー、内部ログ、シークレットではなく、編集された要約や推奨が表示されます。

インタプリートの現状

• ライブネスはAPIプロセスが実行中であることを意味します。
• 準備状態とは、重要な依存関係がフルトラフィックに対応できることを意味します。
• 必要なストレージ障害が発生すると、ライブプロービングが続く間は準備状態が利用できません。
• ドキュメント解析や検索が利用できない場合、すべてのLinkSense機能が使えなくなります。
• 未設定のランカーは有効です。RRFは引き続き利用可能です。

ディスクの使用

ディスク使用量は健康関連のトップサマリーでコンパクトに表示されています。 これには、すべてのユーザーのプロジェクトスペース、タスクアーティファクトや添付ファイル、環境やキャッシュ、さらにデータベース、ナレッジインデックス、バックアップ、ログ、現在の展開のためのサービスプログラムが含まれています。 完了またはアーカイブされたタスクの保持ファイルも含まれています。

測定は割り当てられたファイルシステム領域を使用します。 スパーファイルは割り当てられたサイズを使用します。共有ディレクトリ、ハードリンク、画像レイヤーは一度だけカウントされます。 別々に保存されたコピーは別々にカウントされます。 これはホストの総ディスク使用量ではありません。 その他の展開、グローバルビルドキャッシュ、所有権が確認されていない過去画像は除外されます。 他の展開と共有されたストレージは、帰属ができない場合、未測定とマークされます。 外部サーバー上のデータベース、オブジェクトストレージ、インデックスはローカルディスク使用から除外されており、それらのサービスで別途チェックする必要があります。

サンプリングはサービス開始時に一度始まり、その後バックグラウンドで1時間ごとに実行されます。 新しいスキャンは、前のスキャンがまだ実行中である限り開始されません。 大規模なディレクトリには独立した時間とリソースの制限があります。 その他の健康情報もすぐに表示されます。 ディスク使用量は最初の完全な測定後、自動的に要約に追加されます。 未完成または不完全な測定は非表示のままです。小計は決して総として示されません。 インジケーターにカーソルを合わせるとサンプル時間が表示されます。 スキャンは準備度チェックやタスク実行を妨げず、サンプリング失敗自体がサービス準備度を変えることはありません。

Dockerのデプロイは、既存のWorkerイメージをネットワーク接続なしの一時的な読み取り専用コンテナとして使用します。 ファイル内容を読み取らずにファイルシステムのメタデータを測定し、その後削除されます。 これには既存のDockerソケット権限と読み取り専用スキャン用のコンテナ機能が必要です。 画像や書き込み可能なレイヤーの位置を公開しないストレージドライバーは、それらのカテゴリを測定しないままにします。 ローカルプロセス展開は現在、完全なデプロイメントディスク使用量を報告できません。

データベースの移行やユーザーファイルの改変、再配置、クリーンアップはありません。 既存のストレージを測定するためにRunner、API、Webを更新し、タスク、プロジェクト、アプリケーションは再作成する必要はありません。

サービスリソース使用状況

サービスのリソース使用状況は最新の利用可能なDockerコンテナスナップショットを表示します。 観察不可能な結果は通常、ランナーコントローラに利用可能なDockerソケットや権限がないことを意味します。すべてのコンテナが止まったわけではありません。 カードは診断用で、コンテナの再起動や停止はできません。

資源のクリーンアップに失敗しました

タスクや能力削除後の非同期クリーンアップが繰り返し失敗した場合、システムヘルスはリソースの種類、ステージ、安定理由、試行回数を一覧表示します。 失敗したアイテムを1つまたは全部やり直すことができます。 LinkSenseは状態を再チェックし、アクティブな目標タスクのためにクリーンアップを延期し、他の実行中のタスクを中断しません。

パス境界、権限、ランタイムの状態が不確かな場合は、管理ディレクトリを手動で削除しないでください。 まずデプロイ権限を修正するかRunnerを修正し、その後システムヘルスから再挑戦してください。

すべての知識インデックスを再構築する

埋め込みモデルを変更したり、展開全体のミスマッチを検出した後:

1. モデルと寸法構成が安定しているか確認してください。
2. 完全な再建の影響を読んでください。
3. メンテナンス期間内に始めましょう。
4. 進捗や失敗を監視しましょう。
5. 完了後に回収を確認する。

再構築では展開全体の並行性制限が適用され、失敗したエントリは再試行可能に保たれます。 繰り返しアクションを選択して重複するリビルドを始めないでください。

エスカレーション

展開権限を持つオペレーターは、環境、ネットワーク、または外部サービスの問題を解決しなければなりません。 ヘルスページは外部ドキュメントリング、エラスティックサーチ、モデルサービスコンテナを自動的に作成または再構成しません。

LinkSenseのアップデートを確認しインストールしてください

バージョンの状態を確認する

このページは公式のLinkSense GitHubリリースを確認し、最新および確認時間、公開時刻、リリースノートを表示します。 今すぐ確認を選択して更新するか、GitHubのリリースページを開くと完全な情報が得られます。

チェックに失敗しても他の製品機能には影響しません。 LinkSenseは、利用できないGitHub接続、レート制限、認識されないレスポンスを区別します。 サーバーの脱出を修復するか、制限がクリアされるまで待ってから再挑戦してください。

管理者はアップデートが利用可能になると製品通知を確認できます。 却下はその管理者にのみ適用され、その解除に適用されます。後のリリースでは新しい通知が表示されます。

アップグレードの準備をしてください

1. 現在のバージョンからターゲットバージョンまでのリリースノートを読みましょう。
2. 低トラフィックウィンドウを設定し、システム設定 → システムメンテナンスでユーザーに通知しましょう。
3. ディスク容量、Dockerサービス、ホスト上のPostgreSQLバックアップ場所を確認してください。
4. アップグレード期間中にまたがるべきでないタスクを待つか停止し、管理者がシステムヘルスを開けるか確認してください。

デプロイメントホスト上で実行してください

Linux:

curl -fsSL https://raw.githubusercontent.com/LingX-AI/linksense/main/upgrade.sh | sudo sh

macOS(sudoは使用しないでください):

curl -fsSL https://raw.githubusercontent.com/LingX-AI/linksense/main/upgrade.sh | sh

スクリプトはCoreまたは Fullを検出し、実行中のタスクを待ち、データベース移行前にPostgreSQLのバックアップを作成・検証します。 スクリプトで印刷されたバックアップの場所を保存してください。 移行開始後に失敗しても自動的にデータベースがロールバックされるわけではありません。

メインから展開されたインスタンス

deploy/production/deploy-production.shを使っているインスタンスは、タスク終了を待たずにバージョンを切り替えます。 まずイメージが築かれます。その後、メンテナンスと作業停止が始まります。 既存の会話やファイルは保持されます。 未完了およびキュー中のリクエストは自動的に再生されません。ユーザーは手動で進む前に実際の進捗を確認する必要があります。 すでに送信されたメッセージやその他の外部の変更は元に戻されません。

タスクシャットダウンは、すべてのタスクに対して別々の待機ではなく、短い共有猶予期間を使用します。 バックアップ、移行承認、健康チェックは引き続き必要です。 シャットダウンやタスクステートの永続化が失敗した場合、デプロイメントはエラーを報告し、メンテナンスを有効にしたままにします。 エラーを解決し、以前のサービスを直接再起動するのではなく、再度デプロイを実行してください。

アップグレード後に確認してください

API システム状態、データベース、Redis、ストレージ、Runner、ナレッジパース、検索を開いて検証します。 実行経路を確認するための最小限タスクを1つ実行します。 その後、メンテナンスを早期に終了するか、ウィンドウを切らせましょう。

アップグレードが失敗した場合は、端末出力とバックアップの位置を展開オペレーターのために保持してください。 データベースの状態を確認する前にスクリプトを繰り返し実行しないでください。

監査ログ

イベント

監査エリアには3つのデータ面があります:

• 恒久監査ログアカウントおよび役割の変更、グループ、能力インポートと公開、認証ライフサイクル、ナレッジガバナンス、モデルおよびシステム構成、管理結果をカバーしています。
• タスク実行情報は、タイトル、メッセージ、ダウンロードアクションを含まない、実行状況、能力名、ファイル数のクロスユーザー編集要約です。
• 削除済みタスクの成果物レポートは、コンテンツの閲覧、復元、ダウンロードなしで、アーティファクト数、サイズ、チェックサム状態、削除時間を保持していました。

時間、アクター、ターゲットタイプ、アクション、結果で永久イベントをフィルタリングします。 タスク実行メタデータはプラグイン、スキル、エラーコード、ランナーステータス、アーカイブステータス、作成または実行日などでフィルタリングすることも可能です。 安定したアクション、必要なID、タイムスタンプ、構造化された黒塗りメタデータを検査するためにレコードを開きます。 UIは生のプロトコルフィールドをユーザーコンテンツとして公開しません。

内容境界

Auditは他のユーザーのタスク本体、ファイル、納品コンテンツ、完全なツールの引数、生の第三者応答、パスワード、トークン、APIキー、認証素文、完全なBase URL、内部パスを表示しません。

一部のレコードは送信元IPとユーザーエージェントを制限メタデータとして保持し、ポリシーに従ってのみ表示します。

却下された操作

自己停止、自己降格、最終管理者への挑戦、不正な読み取り、無効なガバナンス要求は安定したエラーコードとともに記録されます。

推奨事項

• まずは狭い時間帯から始めましょう。
• 監査事実のエクスポートや伝達時にデータ最小化ルールを保持します。
• イベントをシステムヘルスのタイムポイントと関連付けてください。
• 事業体が削除された後は恒久的な最小限の監査が行われることを覚悟してください。

ユーザーフィードバックの管理

レビューフィードバック

ページ付きリストには、投稿者、テキスト抜粋、画像数、返信状況、投稿時間が示されています。 全文を読むには表示を選択し、画像プレビューを開きます。 画像が読み込まれない場合は、ユーザーに制御されていないチャネルを通じて機密資料の再送信を求める前にリフレッシュしてください。

フィードバックには、ユーザーが投稿することを選択したビジネス情報が含まれている場合があります。 問題診断のみに使い、ログや公開タスク、無関係な外部サービスへのコピーは避けてください。 フィードバックは監査ログではなく、特定のタスク実行に自動的に結合されるわけでもありません。

ユーザーに返信する

フィードバックの詳細を開き、返信を書くか画像を追加し、返信を送信を選択します。 テキストのみ、画像のみ、そしてまとめて返信することも可能です。 各返信は最大2,000文字と9枚の画像を許可し、1枚の画像あたり最大5 MBまでです。 PNG、JPEG、WebP、GIFに対応しており、貼り付けた画像も含まれます。

複数回返信しても構いません。返信は時系列で掲載されます。 不合格の提出は草稿と選ばれた画像を保存します。 返信が成功すると、ユーザーは「自分のフィードバック」で読むことができ、リストには返信済みが表示されます。 このステータスは問題が解決したことを意味しません。

フィードバックを削除してください

削除するとフィードバック、すべての返信、画像が永久に削除され、元に戻せません。 必要な処理が完了し、組織の定着ルールで削除が許可されていることを確認します。 送信者、タスク、監査記録、使用状況の事実は削除しません。

ハンドリングガイダンス

• まずは報告された時間、ページ数、安定したエラーコードから始めましょう。
• 追加情報は承認された組織のチャネルを通じてのみお尋ねください。
• パスワード、トークン、APIキー、QRコード、一度きりのリンクを要求しないでください。
• システムインシデントについては、報告をシステムヘルスと相関監査ログと関連付けてください。