vague memory

うろ覚えを無くしていこうともがき苦しむ人の備忘録

Macで HTTP Proxy 経由のSSH

macOS からWindows を経由して SSH する機会があったため、調査した内容を残しておきます。
Web上で色々情報が見つかったのですが、現在では古い情報も混ざっているため自分用に整理した内容です。

f:id:htnosm:20190115014841j:plain



要件

macOS -> win_proxy(Windows) -> web(Linux)

上記のように直接接続が許可されていない、win_proxy(WindowsProxyサーバ)の背後のweb(Linuxサーバ)に対し、 macOSからSSH接続を行います。

HTTP CONNECT メソッドで接続を確立しトンネルすることで SSH での接続が可能になります。
環境は以下の通りです。

結果

Nmap付属のncatを使用すると最も環境に依存せずに実現可能と思います。

--proxy-type オプションで "http" を指定します。

Specify proxy type ("http" or "socks4" or "socks5")

$ ssh -o ProxyCommand='ncat --proxy-type http --proxy win_proxy:3128 %h %p' -i ~/.ssh/id_rsa ubuntu@web

# ssh config
Host    web
        Hostname        web
        User            ubuntu
        IdentityFile    ~/.ssh/id_rsa
        ProxyCommand ncat --proxy-type http --proxy win_proxy:3128 %h %p
        ServerAliveInterval 10

Linuxでのncコマンド

-X オプションで "connect" を指定します。

Supported protocols are “4” (SOCKS v.4), “5” (SOCKS v.5) and “connect” (HTTPS proxy).
If the protocol is not specified, SOCKS version 5 is used.

ssh ProxyCommand='nc -X connect -x win_proxy:3128 %h %p' -i ~/.ssh/id_rsa ubuntu@web

# ssh config
Host    web
        Hostname        web
        User            ubuntu
        IdentityFile    ~/.ssh/id_rsa
        ProxyCommand nc -X connect -x win_proxy:3128 %h %p
        ServerAliveInterval 10

Macでのncコマンド

macOS 標準搭載のncコマンドでは接続エラーを解消できずでした。

nc: Proxy error: "HTTP/1.1 200 Connection established" 
ssh_exchange_identification: Connection closed by remote host 

間にLinux等を挟む事で無理やり繋ぐ事は可能です。

ssh ProxyCommand='ssh bastion_linux nc --proxy-type http --proxy win_proxy:3128 %h %p' -i ~/.ssh/id_rsa ubuntu@web

# ssh_config
Host    bastion_linux
        Hostname    bastion_linux
        User        hoge

Host    web
        Hostname        web
        User            ubuntu
        IdentityFile    ~/.ssh/id_rsa
        ProxyCommand ssh bastion_linux nc --proxy-type http --proxy win_proxy:3128 %h %p
        ServerAliveInterval 10

調査

以下メモレベルですが、上記Nmap付属のncat使用に至った経緯です。
無駄に長いので折り畳みます。

続きを読む

Datadog win32_event_log (v6 日本語環境) 訂正

以前 Datadog Agent Version 6 で日本語環境でのイベントログ取得を確認したのですが、 検証に誤りがありました。

htnosm.hatenablog.com

再度確認した所、Agent Version 5 同様、 マルチバイトでは動作しませんでした。

Event Viewer Integration

WindowsイベントログをDatadogへ連携するインテグレーションが用意されていますが、 現時点では日本語環境ではエラーレベルでの絞り込みが行なえません。

カスタムチェック

version 6でも 5 同様のカスタムチェックを作成することで動作が確認できました。

win32_event_log.py から win32_event_log_ja.py を作成します。

  • win32_event_log.py
C:\Program Files\Datadog\Datadog Agent\embedded\Lib\site-packages\datadog_checks\win32_event_log\win32_event_log.py
  • win32_event_log_ja(差分) v6対応版
--- win32_event_log.py
+++ win32_event_log_ja.py
@@ -1,3 +1,12 @@
+#!/usr/bin/python
+# -*- coding: cp932 -*-
+'''
+日本語環境用イベントログ監視(v6)
+'''
+import sys
+reload(sys)
+sys.setdefaultencoding('cp932')
+
 # (C) Datadog, Inc. 2010-2017
 # All rights reserved
 # Licensed under Simplified BSD License (see LICENSE)
@@ -96,6 +105,18 @@
         if ltypes:
             query['Type'] = []
             for ltype in ltypes:
+                if ltype == 'Critical':
+                    ltype = '重大'
+                elif ltype == 'Error':
+                    ltype = 'エラー'
+                elif ltype == 'Warning':
+                    ltype = '警告'
+                elif ltype == 'Information':
+                    ltype = '情報'
+                elif ltype == 'Audit Success':
+                    ltype = '成功の監査'
+                elif ltype == 'Audit Failure':
+                    ltype = '失敗の監査'
                 query['Type'].append(('=', ltype))
         if source_names:
             query['SourceName'] = []
@@ -233,9 +255,11 @@
     def _alert_type(self):
         event_type = self.event['Type']
         # Convert to a Datadog alert type
-        if event_type == 'Warning':
+        if event_type == '警告':
             return 'warning'
-        elif event_type == 'Error':
+        elif event_type == '重大':
+            return 'error'
+        elif event_type == 'エラー':
             return 'error'
         return 'info'

win32_event_log_ja.py を checks.d、win32_event_log_ja.yaml(中身はwin32_event_log.yamlと同じ) を conf.d に格納して使用します。

C:\PROGRAMDATA\DATADOG
├─checks.d
│      win32_event_log_ja.py
├─conf.d
│  ├─win32_event_log_ja.d
│  │      conf.yaml

実行結果例

f:id:htnosm:20190111044426p:plain f:id:htnosm:20190111043855p:plain

システムアカウントの言語設定

尚、ログインユーザの言語設定が日本語でも、 システムアカウントの言語設定を英語としておけば、 そのまま win32_event_log を利用できます。

  • [コントロールパネル] -> [地域] -> [管理] -> [設定のコピー]

f:id:htnosm:20190111044155p:plain

ようこそ画面の欄がシステムアカウント設定も含むようです。

AWS API Call 数の取得

AWSの監視をCloudWatch以外(SaaS等)で行っている場合に、AWS API のコール数が気になります。
CloudTrail で証跡を保存、解析すれば詳細に分析できると思いますが、諸事情によりその手法が使えなかったので調べてみました。



AWSサービス

関連するAWSサービスの概要です。

CloudTrail Event

APIの実行履歴は CloudTrail Event で表示・取得できます。

CloudTrail は、作成時に AWS アカウントで有効になります。AWS アカウントでアクティビティが発生した場合、そのアクティビティは CloudTrail イベントに記録されます。

f:id:htnosm:20180917013940p:plain

Trail(証跡)が有効である必要はありません。ここでのTrail(証跡)は S3 等への転送を指します。

Trail(証跡)

CloudTrail Event を S3バケットや CloudWatch Logs へ転送する設定が行なえます。

Amazon Macie

機械学習によるユーザ動向の分析が行えるサービスです。

データソースとして AWS CloudTrail イベントログを利用できます。上記 Trail(証跡) を使用します。 また、現時点ではバージニアオレゴンリージョンのみの提供です。

f:id:htnosm:20180917013936p:plain

主要なSaaSAPI実行間隔

AWSの統合機能がある主要な SaaSAPI 実行間隔の情報です。

Datadog

We use the CloudWatch monitoring APIs to monitor your AWS resources. Our main use of these APIs is to gather raw metrics data through the GetMetricStatistics endpoint.

By default, we collect AWS metrics every 10 minutes.

デフォルトでは10分間隔で収集します。サポートへの依頼で間隔を変更することができます。

現時点では API コール数を参照する方法は用意されておらず、 AWS Biling インテグレーションを利用し、請求額を参照する事で把握する方法が紹介されています。

Mackerel

5分ごとに取得対象となるメトリックの数だけAWSAPIをコールして値を取得します。

New Relic

By default, the polling interval frequency is set to the maximum. You can change the polling frequency in the configuration settings.

サービス毎に異なり、デフォルトでは 1分 or 5分毎となるようです。[Configure]から設定変更も可能です。

AWS Account Status Dashboard からAPIコール数を参照できるようです。

可視化してみる

New Relic の AWS Account Status Dashboard と同等の物を Datadog で作成してみます。

定期的に CloudTrail Event を収集し、サマリを Datadog のカスタムメトリクスとして登録します。
今回は Datadog AWSインテグレーション用IAMロールを対象とし、Datadog へ送信していますが、仕組み的に応用は効きそうです。

f:id:htnosm:20180917013932p:plain

host を aws_account_no として登録しています。

f:id:htnosm:20180917020345p:plain

尚、Datadog で Custom Metrics を扱うには有償プランである必要があるようです。

留意点

LookupEvents を使用して CloudTrail Event を取得します。

The rate of lookup requests is limited to one per second per account. If this limit is exceeded, a throttling error occurs.

Lookup には1秒に1回の実行制限があります。

Events that occurred during the selected time range will not be available for lookup if CloudTrail logging was not enabled when the events occurred.

logging が有効であることが条件との記載がありますが、確認した限りではTrail(証跡)を有効化していないリージョンでも取得が行えていました。

CloudTrail typically delivers log files within 15 minutes of account activity.

Event が即時反映されないように見えたので、ドキュメントにあるよう、15分前の値を取得しています。

CloudWatch supports logging the following actions as events in CloudTrail log files:

Trail に出力されるAPIのみが対象になります。 叩かれているであろう GetMetricStatistics 等は残念ながら対象外です。

没案

CloudWatch のカスタムメトリクスとして登録する方法も考えましたが、 リージョン跨いで参照したかったのと、APIコール数参照のためにAPIコール数を増やすのもいかがなものかと思い、止めました。

f:id:htnosm:20180917013928p:plain

Datadog Logs Windows上の日本語ログ(SJIS)登録

Windows 上の Datadog Agent v6 でのログを tail で収集する場合、対象のログファイルは UTF8 である必要があるとのことです。

Note: If you are using the Windows 6 Agent and trailing files for logs - make sure that those files have a UTF8 encoding.

SJISのログを送信すると文字化けしてしまうので、UTF8へ変換しつつのログ送信を検証します。
Datadogのマニュアルに未サポートのログファイルに対しては、ログ転送ソフトを介して送信するよう案内があります。 td-agent 3 が Windows をサポートしたので、今回は td-agent(fluentd) を使用します。

f:id:htnosm:20180811161224p:plain



環境

  • Windows Server 2012 R2 Standard
    • Datadog Agent Version 6.3.3
    • td-agent Version v3.1.1 (Fluentd v1.0.2)

対象ログファイル

以下の様な Shift_JIS 日本語を含むログファイルを対象とします。

f:id:htnosm:20180811162717p:plain

設定

Datadog Agent

ログ収集機能を有効化します。

  • [Datadog Agent Manager] -> [Settings]
    • 実体は C:\ProgramData\Datadog\datadog.yaml
log_enabled: true

カスタムログ用ファイル格納

任意の名称で設定ファイルを格納します。

mkdir C:\ProgramData\Datadog\conf.d\customlog.d
echo. > C:\ProgramData\Datadog\conf.d\customlog.d\conf.yaml

ディレクトリとファイルを作成することで、 GUI にも表示されるようになります。

  • [Datadog Agent Manager] -> [Checks] -> [Manage Checks]

Datadog Agent (v6)

datadog-agent(v6) 標準機能でのログ収集設定です。

  • customlog.d\conf.yaml
logs:

  - type: file
    path: C:\log\test.log
    service: app
    source: customlog

結果例

  • 文字化けする

f:id:htnosm:20180811161216p:plain

fluentd(td-agent)

fluentd で変換して取り込む設定です。 2パターン検証しましたが、いずれでも日本語文字列の文字化けは回避できました。

td-agent3 から Windows をサポートしています。

現時点での最新版 version v3.1.1 からは beta の文字が取れていました。

f:id:htnosm:20180811163048p:plain

文字コード変換には fluent-plugin-record-modifier の char_encoding を使用します。

設定

プラグインインストール

td-agent をインストールすると td-agent command prompt が利用できますので、そこからプラグインをインストールします。

f:id:htnosm:20180811162934p:plain

C:\opt\td-agent>fluent-gem install fluent-plugin-record-modifier
WARN: Unresolved specs during Gem::Specification.reset:
      win32-api (>= 1.4.5)
WARN: Clearing out unresolved specs.
Please report a bug if this causes problems.
Fetching: fluent-plugin-record-modifier-1.1.0.gem (100%)
Successfully installed fluent-plugin-record-modifier-1.1.0
Parsing documentation for fluent-plugin-record-modifier-1.1.0
Installing ri documentation for fluent-plugin-record-modifier-1.1.0
Done installing documentation for fluent-plugin-record-modifier after 0 seconds
1 gem installed

ログディレクト

pos ファイル格納用のディレクトリを作成しておきます。

C:\opt\td-agent>mkdir var\log

td-agent.conf

td-agent.conf は以下に格納されています。

C:\opt\td-agent\etc\td-agent\td-agent.conf

tail Input と record-modifier の設定を行います。

<source>
  @type tail
  path C:\log\test.log
  pos_file C:\opt\td-agent\var\log\test.log.pos
  tag fluentd.raw
  format none
</source>

<match fluentd.raw>
  @type record_modifier
  tag fluentd.encode
  char_encoding Windows-31J:utf-8
</match>

a) fluent-plugin-datadog

Datadog 公式のプラグインです。

インストール

C:\opt\td-agent>fluent-gem install fluent-plugin-datadog
WARN: Unresolved specs during Gem::Specification.reset:
      win32-api (>= 1.4.5)
WARN: Clearing out unresolved specs.
Please report a bug if this causes problems.
Fetching: fluent-plugin-datadog-0.10.4.gem (100%)
Successfully installed fluent-plugin-datadog-0.10.4
Parsing documentation for fluent-plugin-datadog-0.10.4
Installing ri documentation for fluent-plugin-datadog-0.10.4
Done installing documentation for fluent-plugin-datadog after 0 seconds
1 gem installed

設定

以下の様に設定します。 (便宜的に store を使用していますが、出力先が一つであれば不要です)

<match fluentd.encode>
  @type copy
  <store>
    @type datadog
    @id awesome_agent
    api_key <your api key>

    # Optional
    include_tag_key true
    tag_key 'tag'

    # Optional parameters
    dd_source customlog
    dd_tags 'host:WIN-XXXXXXXXXXX,service: app,filename:test.log'
    dd_sourcecategory multibytes
  </store>
</match>

結果例

  • 文字化け解消
  • Host、Serviceが付かない
    • dd_tags で Tag を付与しているが、一覧上は抜けた状態

f:id:htnosm:20180811161355p:plain f:id:htnosm:20180811161351p:plain

b) file Output Plugin

fluentd 標準で何とかする案です。変換後のファイルを Datadog Agent に読ませます。

設定

以下の様に設定します。

<match fluentd.encode>
  @type copy
  <store>
    @type file
    path C:\log\test.utc8.log
    append true
  </store>
</match>
  • customlog.d\conf.yaml
logs:

  - type: file
    path: C:\log\test.utc8.log\*.log
    service: app
    source: customlog

結果例

  • 文字化け解消
  • Datadog Agent 側の設定に沿って Host,Servce,Source が付与
  • ログ部分は JSON 形式 {"message": ""}

f:id:htnosm:20180811161347p:plain

サービス化

公式の手順通りに fluentd を Windows サービス化します。

  • td-agent command prompt
fluentd --reg-winsvc i
fluentd --reg-winsvc-fluentdopt '-c C:/opt/td-agent/etc/td-agent/td-agent.conf -o C:/opt/td-agent/var/log/td-agent.log'

f:id:htnosm:20180811163137p:plain

折角なので fluentd の監視 ( FluentD ) も入れます。

  • td-agent.conf
<source>
  type monitor_agent
  bind 0.0.0.0
  port 24220
</source>
  • Datadog (conf.d/fluentd.yaml)
init_config:

instances:
    -  monitor_agent_url: http://example.com:24220/api/plugins.json

f:id:htnosm:20180811161336p:plain


まとめ

日本語ログは扱いに困ります。

  • Windows での Datadog Agent(v6) Logs は UTF8 でないと文字化けする
  • UTF8 へ変換することで文字化けは解消可能(今回は fluentd を利用)
    • a案 fluent-plugin-datadog は Host、Service が付与されない
    • b案 file Output で別ファイルに書き出す事場合は出力形式が変わる

公式プラグインがイマイチだったのでb案を試してみた感じですが、性能面は全く見てないので実際使えるかは要検証です。

Datadog win32_event_log (v6 日本語環境)

以前日本語環境のWindows上で、イベントログ送信がうまく動作しなかったので現状(v6)ではどうなっているのかを確認します。 また、 Logs での連携も追加されているので併せて確認します。

結果 Agent Version 6 でのマルチロケーション対応はされており、そのまま利用できました。

  • 2019/01/09 追記

Win32eventlog について、検証に誤りがありました。 再度確認した所、Agent Version 5 同様、日本語対応は為されていませんでした。 システムアカウントの言語設定が日本語だと動作しません。 下記確認はログインユーザの言語設定のみ日本語にした状態での実施でした。



環境

確認した環境は以下です。

  • Win 2012
Agent Version: 6.3.3
Go Version: 1.10.3 
Platform: Windows Server 2012 R2 Standard
Platform Version: 6.3 Build 9600
  • Win 2018
Agent Version: 6.3.3
Go Version: 1.10.3 
Platform: Windows Server 2016 Datacenter
Platform Version: 10.0 Build 14393
  • 日本語化

イベントビューアーは日本語で表示されている状態です。

f:id:htnosm:20180730032744p:plain

サービスチェック

Datadog Agent Manager にてインテグレーション設定を追加します。

  • [Checks] -> [Manage Checks] -> [Add a Check]
    • [win32_event_log]

設定ファイルの内容は以下のようにしています。

  • win32_event_log.d/conf.yaml
init_config:

instances:

  - log_file:
      - System
    type:
      - Error
    tags:
      - system

イベントビューアー上で "エラー" を発生させると、Datadog Events 上への通知を確認できます。

f:id:htnosm:20180730032741p:plain

Logs

Logs での取得も確認します。

設定ファイル(win32_event_log.d/conf.yaml)に logs ディレクティブ を追加します。

logs:
  - type: windows_event
    channel_path: System
    source: System
    service: eventlog
    sourcecategory: windowsevent

channel_path へは LogName を指定します。 LogName は PowerShell コマンドで参照できます。

Get-WinEvent -ListLog *

f:id:htnosm:20180730032737p:plain

  • Datadog Logs

f:id:htnosm:20180730032733p:plain

Status Remap

ここまでは特に躓かずに設定できたのですが、少々違和感が残ります。

イベントビューアー上、"エラー"や"警告"であるにも関わらず、Datadog Logs での Status が全て "INFO" になってしまいます。

他に良い方法があるかもしれませんが、下記の様に設定追加を行うことで Status を認識させる事ができました。(直接Remapすれば良さそうですが、効かなかったので一段噛ませています)

facet

facet と呼ばれる属性値を作成します。 Event.System.Level にイベントビューアー上のレベルに対応するエラーレベルがあります。

  • [Logs] -> [Explorer]
    • 対象のログ詳細上の [ATTRIBUTES]
      • Create facet for @Event.System.Level

f:id:htnosm:20180730032730p:plain

facet 作成後にログを受信すると左ペインにフィルタ用のチェックボックスが出力されます。

f:id:htnosm:20180730032831p:plain

Pipelines

Windows Eventlog 用の Pipeline を作成します。

  • [Logs] -> [Pipelines] -> [New Pipeline]
    • Filter: service:eventlog
    • Name: windowsevent

f:id:htnosm:20180730032828p:plain

Category Processor

上記 Pipeline にカテゴリプロセッサを作成します。 作成済みの facet "@Event.System.Level" に対し、それぞれ以下の値を置き換えます。

Name MATCHING QUERY Event Viewer EntryType
Critical @Event.System.Level:2 Error(エラー)
Warning @Event.System.Level:3 Warning(警告)
Info @Event.System.Level:4 Information(情報)

f:id:htnosm:20180730032824p:plain

Status Remapper

作成したカテゴリをステータスに割り当てます。

f:id:htnosm:20180730032821p:plain

Status Remap 結果

正常に認識されると Datadog Logs 上の Status での絞り込みが可能になります。

f:id:htnosm:20180730032818p:plain

Datadog Logs アーカイブ機能の追加等

Datadog Logs のアップデートがありました。 大きく以下3つの機能が追加されています。

  • Introducing Logging without Limits
    • Limitless Logs
      • ログ取り込みとインデキシング(フィルタリング)の分離
    • Archive Logs
      • ストレージ転送
    • Live Tail
      • リアルタイムログストリーム

既に公式ドキュメントも公開されていますが、ポイントを整理します。



f:id:htnosm:20180720143657p:plain

Limitless Logs

送信元でのフィルタを行わず、 Datadog 管理画面上でフィルタが可能です。 フィルタにより除外されたログは、Datadog Logs 課金対象からも除外されます。 後述 Archive の対象となるので、収集・保存のみ行える事になります。(保存先の料金は掛かります)

Live Tail には含まれるので、Live Tail で参照しつつ、除外条件を作成していく流れになると思います。

[Logs] -> [Pipelines] -> [INDEXES] -> [Add an Exclusion Filter] より除外フィルタを作成します。

f:id:htnosm:20180720141750p:plain

クエリによる除外フィルタ、サンプリングレートの指定と有効/無効切替が行えます。

f:id:htnosm:20180720141746p:plain

尚、送信元(Datadog Agent)側でフィルタしたい(送信対象としない)場合は、log_processing_rules で exclude_at_match や include_at_match を使用します。

Archive Logs

AWS S3 へのアーカイブ機能です。 AWS インテグレーションで使用している AWS アカウントとは関連無く、任意の S3 バケットへのログ転送が行えます。

転送されるログは、PIPELINES(Processor)経由後のログです。INDEXES(Exclusion Filter)有無は関係ありません。

公式ブログ上に (with support for other endpoints to come) とあるので、今後S3以外のストレージが追加されそうですが、現状は AWS S3 のみのサポートです。

設定には Datadog の管理者権限(Admin User) が必要です。管理者以外は設定の参照は可能ですが、変更はできません。

[Logs] -> [Pipelines] -> [ARCHIVES] で送信先のS3バケットを指定します。

Configure S3 Bucket

送信先S3バケットに公式記載のバケットポリシーを設定します。

Define Archive

S3 Bucket と Path を設定します。

f:id:htnosm:20180720141741p:plain

設定後から、取り込まれたログが Pipeline 経由後、S3バケットに転送されます。 15分程待つとS3バケットへの転送されていることが確認できます。

Changes have been made to this archive. It can take a few minutes before the next upload attempt.

フォーマット

/my/s3/prefix/dt=20180515/hour=14/archive_143201.1234.7dq1a9mnSya3bFotoErfxl.json.gz

  • gzip された JSON
  • 日付、時間の HIVE フォーマット

以下 Nginx access.log のJSON出力例です。 attributes はパース結果が反映されます。

{
  "_id": "AWS1oRxxxxxxxxx1bnTi",
  "date": "2018-07-ddThh:mm:ss.0000",
  "service": "nginx",
  "host": "i-xxxxxxxxxxxxxxxxx",
  "attributes": {
    "http": {
      "status_code": 200,
      "referer": "-",
      "useragent": "Datadog Agent/0.0.0",
      "method": "GET",
      "url": "/",
      "version": "1.1",
      "url_details": {
        "path": "/"
      },
・・・・
  },
  "source": "nginx",
  "message": "127.0.0.1 - - [dd/Jul/2018:hh:mm:ss.0000] \"GET / HTTP/1.1\" 200 396 \"-\" \"Datadog Agent/0.0.0\"",
  "status": "ok"
}

画面上に Main Archive とあるので、複数指定が可能なのかと思いましたが、現状で設定できるのは単一送信先のようです。(契約プラン等で変わるのかもしれません)

また、faset(tag)によるパスやファイルの振り分けは行われません。S3上へ転送したログを検索する際は Athena 等を利用する必要がありそうです。

Live Tail

(ほぼ)リアルタイムにログイベントを参照できます。

  • PIPELINES(Processor)経由後、INDEXES(Exclusion Filter)前
  • ストリーム表示の一時停止は可能
  • 過去へ遡る事はできない

リアルタイム版 Explorer のような感じです。

Slack ユーザメンションの仕様変更 (Datadog例)

結構前からアナウンスはされているのですが、すぐ忘れるので残しておきます。
Datadog だけでは無いですが、Slack側仕様変更により、Slack上の個別ユーザへメンションする際の指定の仕方が変わります。

The undocumented approach to mentioning users via the API — <@username> — will no longer function after September 12, 2018. Please reference with the user ID format (<@U123>) instead

既に始まっていて、使えなくなっている状況もあるようです。

Datadog Monitor → Slack

Slack Integration を設定することでSlackへの通知が可能です。 @slack-〜 でSlackチャンネルへの通知設定を入れている状態で以下のようにするとユーザメンションになります。

不等号(<>) で囲って @ユーザ名

<@slackbot>

不等号(<>) で囲って @ユーザID

<@USLACKBOT>

username_like_string とやらも使えるようですが、 試した所特に Alias としては機能していないようでした。Slackとしては非推奨のようなので利用しない方が良いかと思います。

  • いずれも Slack 上では @slackbot として見える
<@USLACKBOT|slackbot> 
<@USLACKBOT|hoge>

アナウンスメンション

@here@channel での通知設定も可能です。

<!here>
<!channel>

チャンネルIDのリンク

#general のようなチャンネルのリンクを通知に載せたい場合は #にチャンネルIDです。
存在しないIDを指定すると #unknown-channel と変換されました。

<#channelid>

Slack の ID

APIで取得するか、後述する方法で取得できます。

ユーザID (member ID)

クライアントからは以下のように取得が可能です。

  • [View profile] -> [Copy member ID]

f:id:htnosm:20180514031355p:plain

チャンネルID

対象のチャンネルを右クリック -> [Copy URL]

# XXXXXXXXX = Channel ID
https://*****.slack.com/messages/XXXXXXXXX

f:id:htnosm:20180514030521p:plain


別途お知らせはあると思いますが、 <@username> 形式は 2018/09/12 で廃止されるとのことなのでお気をつけください。