1

今週は RSS フィードをいじっていましたが、次のトリックとして、内部アプリケーション ログ用の RSS フィードを作成したいと考えています。無数のバッチ アプリとイントラネット アプリがログ メッセージを投稿するために使用する集中データベース テーブルがあります。このテーブルから RSS フィードを作成したいのですが、ボリュームを処理する方法がわかりません。通常の日でも、1 日あたり何百ものエントリがある可能性があります。やめたくなる特別な日は、数千人に見られるかもしれません。何かご意見は？

4

6 に答える 6

3

フィードを静的ファイル(何千ものファイルを簡単に提供できます) にし、定期的に再生成します。1 秒未満で実行する必要がなく、数分実行することもできるため、より幅広い選択肢があります。また、ユーザーは依然として完璧なダウンロード速度と適切な更新速度を得ることができます。

于 2008-09-17T12:58:11.063 に答える
2

見逃してはならない通知を備えたシステムを構築している場合は、pub-sub メカニズム (XMPP、ApacheMQ でサポートされている他のプロトコルの 1 つ、または同様のものを使用) が、シンジケーション メカニズムよりも適しています。コンシューマが通知を見逃さないようにするために、通知を生成しているシステムとそれらを消費しているシステムとの間の結合の何らかの手段が必要です。

(RSS または Atom をトランスポート形式として使用してこれを行うことができますが、おそらく一般的なユース ケースではありません。表示される通知は、コンシューマと以前に表示された通知に基づいて変更する必要があります。)

于 2008-09-15T16:16:49.620 に答える
1

フィードを可能な限り分割し、ユーザーが必要に応じて再結合できるようにします。もし私がそうしていたら、おそらく Django とシンジケート フレームワークを使用することを考えるでしょう。

Django のモデルは、関心のあるテーブルのデータ構造の表現をおそらく処理できます。

次のように、すべてをキャッチする URL を作成できますr'/rss/(?(\w*?)/)+'(うまくいくと思いますが、今はテストできないため、完全ではない可能性があります)。

そうすれば、次のような URL を使用できます (例の URL の自動リンクをキャンセルするように編集されています)。

  • http://feedserver/rss/batch-file-output/
  • http://feedserver/rss/support-tickets/
  • http://feedserver/rss/batch-file-output/support-tickets/ (最初の 2 つの両方を 1 つに結合)

次に、ビューで：

def get_batch_file_messages():
    # Grab all the recent batch files messages here.
    # Maybe cache the result and only regenerate every so often.

# Other feed functions here.

feed_mapping = { 'batch-file-output': get_batch_file_messages, }

def rss(request, *args):
    items_to_display = []
    for feed in args:
        items_to_display += feed_mapping[feed]()
    # Processing/returning the feed.

個別の連鎖可能なフィードを持つことは、ユーザーが一度に 1 つのフィードを購読したり、関心のあるフィードを 1 つの大きなフィードにマージしたりできることを意味します。彼らにとって読みやすいものは何でもできます。

于 2009-01-07T18:51:12.513 に答える
0

この場合、管理者のダッシュボードのようなものです。今日サポートに投入された作業量、現在ログに差し迫っているものはありますか、夜間のバッチ ジョブで問題が発生したかの尺度として、朝に最初に到着した時刻などです。 .

于 2008-09-15T19:05:13.943 に答える
0

さて、これをどう処理するか決めました。各列にタイムスタンプ フィールドを使用し、日ごとにグループ化しています。もちろん、そこには完全なタイムスタンプがあり、グループ内から表示するログメッセージを選択する方法についてある程度知性を持つ必要があるため、それを実現するには少しSQL-fuが必要ですが、それほど悪くはありません. さらに、監視するアプリケーションを選択して、特定の日からのすべてのメッセージ (最大 50) を表示できるように構築しています。

それは私を合理的なものに導きます。

より一般的な質問への適切な回答を期待しています。

于 2008-09-15T16:10:20.260 に答える
0

あなたのアプリケーションを知らなければ、私は具体的なアドバイスを提供することはできません.

とはいえ、この種のシステムでは重大度レベルを持つのが一般的です。重大度を指定する URL の末尾に追加するクエリ文字列パラメーターを使用できます。「DEBUG」に設定すると、どんなに些細なことでも、すべてのイベントが表示されます。「FATAL」に設定すると、「システム障害」の規模のイベントのみが表示されます。

それでもイベントが多すぎる場合は、イベントを何らかのカテゴリ システムに細分化することをお勧めします。繰り返しますが、これをクエリ文字列パラメーターとして使用します。

その後、さまざまなカテゴリと重大度の複数の RSS フィードを持つことができます。これにより、アラートのレベルを許容レベルに調整できるようになります。

于 2008-09-12T21:59:32.130 に答える