21. 11. 2022 Juergen Vigna NetEye, Unified Monitoring

Monitor Your SMS Gateways by Sending Actual SMS’s (Part 2/2)

Last time I wrote about how you can have incoming SMS messages sent to the Tornado Engine so that you can make Tornado Rules to process them. This time I’d like to show you a real use case where we check whether the SMS Gateway is really working or not by sending an SMS to itself and checking that it’s received correctly.

On every Server that you have a SMS Gateway connected to, you’ll have 2 services being monitored: an active service that sends an SMS (SMS_Send) and a passive one which is set by Tornado when the SMS is correctly received (SMS_Receive).

For the active SMS_Send service you can use this small plugin script (/neteye/shared/monitoring/plugins/check_send_sms.sh), which sends an SMS message using the sendsms.sh script (alternatively you can also use the /usr/bin/smssend script installed with the smstools package).

#! /bin/sh
#
SMSCMD=/usr/local/bin/smssend.sh
SMSSPOOL=/neteye/local/smsd/data/spool
WAITSEC=30

NUMBER="$1"
shift
TEXT="$@"

$SMSCMD "$NUMBER" "$TEXT"

while [ $WAITSEC -gt 0 ]
do
	if grep "$TEXT" $SMSSPOOL/checked/* >/dev/null 2>&1
	then
		echo "OK - SMS in checked queue"
		exit 0
	fi
	sleep 1
	WAITSEC=$(expr $WAITSEC - 1)
done

if grep "$TEXT" $SMSSPOOL/outgoing/* >/dev/null 2>&1
then
	echo "WARNING - SMS in outgoing queue. SMS Daemon not running?"
	exit 1
fi

echo "CRITICAL - SMS has not been queued or an error sending occurred"
exit 2

This script sends an SMS message and then checks that the SMS Daemon has at least placed it in the checked directory.

Next, you configure this active service in Icinga 2 with the plugin script and for instance run it once a day (i.e., every 24h).

The SMS is then sent by the Gateway and as it is sent to itself, it should then also be received by the SMS Gateway. ATTENTION: in the smsd.conf file there must be the configuration “incoming = yes“, which normally should be activated by default. Once we have incoming SMS’s received and forwarded to Tornado, we can now create a Tornado Rule to handle this webhook-sms event and pair our passive service with an Icinga 2 action.

Above you can see that in the FROM Clause I put 2 phone numbers, so in this case ONLY SMS messages received from these 2 numbers can trigger the SMS_Receive service. The HOST variable is set from the data since it already contains the hostname that the SMS Gateway is attached to.

You may also use this file block and copy it into the SMS_Receive rule you generated with the Tornado WUI.

{
  "name": "SMS_Receive",
  "description": "Receive SMS from local Modems and set SMS_Receive service of the host",
  "continue": false,
  "active": true,
  "constraint": {
    "WHERE": {
      "type": "AND",
      "operators": [
        {
          "type": "regex",
          "regex": "webhook-sms",
          "target": "${event.type}"
        }
      ]
    },
    "WITH": {
      "RECEIVED": {
        "from": "${event.payload.received}",
        "regex": {
          "match": ".*",
          "group_match_idx": 0,
          "all_matches": false
        },
        "modifiers_post": []
      },
      "MODEM": {
        "from": "${event.payload.modem}",
        "regex": {
          "match": ".*",
          "group_match_idx": 0,
          "all_matches": false
        },
        "modifiers_post": []
      },
      "HOST": {
        "from": "${event.payload.host}",
        "regex": {
          "match": ".*",
          "group_match_idx": 0,
          "all_matches": false
        },
        "modifiers_post": []
      },
      "FROM": {
        "from": "${event.payload.from}",
        "regex": {
          "match": "(39111222333444|39555666777888)",
          "group_match_idx": 0,
          "all_matches": false
        },
        "modifiers_post": []
      },
      "SENT": {
        "from": "${event.payload.sent}",
        "regex": {
          "match": ".*",
          "group_match_idx": 0,
          "all_matches": false
        },
        "modifiers_post": []
      },
      "DATA": {
        "from": "${event.payload.data}",
        "regex": {
          "match": ".*",
          "group_match_idx": 0,
          "all_matches": false
        },
        "modifiers_post": []
      }
    }
  },
  "actions": [
    {
      "id": "icinga2",
      "payload": {
        "icinga2_action_name": "process-check-result",
        "icinga2_action_payload": {
          "exit_status": "0",
          "filter": "host.name==\"${_variables.HOST}\" && service.name == \"SMS_Receive\"",
          "performance_data": "",
          "plugin_output": "OK - ${_variables.SENT}: ${_variables.DATA}\nReceived: ${_variables.RECEIVED}\nSent: ${_variables.SENT}\nModem: ${_variables.MODEM}",
          "type": "Service"
        }
      }
    }
  ]
}

Now you’re monitoring your SMS Gateway as it sends real SMS’s to itself, so you’ll know that it’s actually online and working. The SMS_Receive service should be a PASSIVE service with a Freshness check, in our case I set the Freshness (check_interval) to 36h since I send an SMS every 24h. This means that if no SMS has been received by the Modem within 36h, it will change to WARNING in my case, but you can choose whatever state you want for your freshness check_dummy check.

These Solutions are Engineered by Humans

Did you like this article? Does it reflect your skills? We often get interesting questions straight from our customers who need customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth Phoenix.

Juergen Vigna

NetEye Solution Architect at Würth Phoenix

I have over 20 years of experience in the IT branch. After first experiences in the field of software development for public transport companies, I finally decided to join the young and growing team of Würth Phoenix. Initially, I was responsible for the internal Linux/Unix infrastructure and the management of CVS software. Afterwards, my main challenge was to establish the meanwhile well-known IT System Management Solution WÜRTHPHOENIX NetEye. As a Product Manager I started building NetEye from scratch, analyzing existing open source models, extending and finally joining them into one single powerful solution. After that, my job turned into a passion: Constant developments, customer installations and support became a matter of personal. Today I use my knowledge as a NetEye Senior Consultant as well as NetEye Solution Architect at Würth Phoenix.

Author

Juergen Vigna

Latest posts by Juergen Vigna

23. 02. 2024 Log-SIEM, NetEye, Unified Monitoring

Monitoring Logs in Elasticsearch: A Practical Example

22. 12. 2023 Log-SIEM, NetEye, Unified Monitoring

SIEM: Monitor Hosts Sending Data to Elasticsearch

30. 11. 2023 Log Management, Log-SIEM, NetEye, Unified Monitoring

Monitor Your Elasticsearch Agents Registered in the Elastic Fleet Server

25. 09. 2023 Icinga Web 2, NetEye, Unified Monitoring

Monitoring Downtime Automation from Windows

28. 04. 2023 Icinga Web 2, NetEye, Unified Monitoring

Elasticsearch Snapshots and How to Monitor Them

See All