Linuxのパッケージをアップデートしたあとrestartが必要なプロセスを見つける方法 - Qiita
はじめに 脆弱性対応のためのアップデート作業というものは頻繁に発生するものですが、本番運用しているシステムではサービスへの影響を最小限にしたいものです。 アップデートした後、出来ることなら必要なプロセスだけリスタートさせることで済ませたいのですが、どのプロセスをリスタートすれば良いのか、そもそもOS再起動しないと反映されないものなのか、判断が付かない場合が少なくありません。 そのような場合のため、再起動が必要なプロセスを見つけたり、OS再起動が必要かどうかアドバイスしてくれるコマンドがあります。 Redhat系 「yum-utils」パッケージに入っている「needs-restarting」コマンドを使います。 # needs-restarting -h Usage: needs-restarting: Report a list of process ids of programs th
脆弱性スキャナVulsのスキャン結果をZabbixへ連携しアラート通知する - Qiita
はじめに 「Zabbixに登録されたホスト情報を脆弱性スキャナVulsへ自動連携する」で少し触れましたが、Vulsでスキャンした結果のJSONファイルを加工（Gist：vuls scan&zabbixにsend）することでZabbixに検知結果を連携することができます。 そしてZabbixへ連携し柔軟なトリガーと通知機能を使うことで、前回スキャン時との比較で検知数が増加した（新しい脆弱性を発見した）ときのみアラート通知する仕組みを作ることができます。 今回は自動運用するために以下のフローを一つのスクリプトで実行するようにします。 脆弱性情報(NVD・JVN)アップデート ↓ Vulsでスキャン ↓ Zabbixへ結果連携 ↓ Vuls JSONファイルのローテーション 「Vuls JSONファイルのローテーション」はVulsRepoで結果を閲覧する際に、毎日スキャンしているとファイル選択ツ
脆弱性検知ツールVulsで前日分との差分だけレポートする - Qiita
はじめに 脆弱性検知ツールVulsを使うとシステムに内在する脆弱性を一発で俯瞰することができ、非常に便利です。 ただ実際には、運用的にステージング環境で検証を行ったあとサービスのメンテナンス時間にアップデート作業を行うため、直ぐに最新版を適用することが難しかったり、脆弱性の深刻度・攻撃元区分(ローカルかリモートか）によっては適用しないといった判断をすることもあるかと思います。 そういった場合、Vulsで毎日自動スキャンしたあと見つかった脆弱性全部をレポートするのではなく、前日との差分だけ通知してくれたほうが運用的に管理しやすい場合もあります。 導入については各所に纏まった手順があるため、今回はスキャン後の差分レポートの作成についてのみ記載したいと思います。 スキャン後にレポートの差分だけメールする 当初、スキャンが終了したホストの順でレポート結果が出力されていたためタイミングによって順番が
ZabbixとSlackでChatOpsのススメ - Qiita
この記事は Zabbix Advent Calendar 2015 の17日目の記事です。 今回はZabbixとSlackを連携させてChatOpsっぽいことをやってみました。 はじめに みなさんはZabbixからのアラート通知はどのようにしていますか？ オペレータからの電話？ メール？ チャット？ 手段は色々ありますが、個人的に感じるそれぞれの問題についてまとめてみました。 電話連絡の問題 オペレータによる24時間365日体制の運用が必要 ⇒高コスト、高負荷。 受け手が対応できない状況にある場合でも、通知する側は知るすべがない ⇒通知する側、受ける側に無駄な対応時間が発生 情報伝達量の限界 ⇒アラートが複数同時発生した場合やログメッセージの場合、全部伝えるのは時間が掛かりすぎる 伝達内容の不正確性 ⇒伝える側の伝え誤り and 受け手の聞き漏らし・聞き間違い 受け手が後から通知された内容
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
