A: Yes, you can obfuscate or alias hostnames starting with SPM client version 1.17.7. This feature allows you to:
To achieve this, after SPM client is installed, open /opt/spm/properties/spm-sender.properties file and just add desired hostname to the value of property spm_sender_hostname_alias, e.g. spm_sender_hostname_alias=web1.production.
After that, restart SPM monitor with:
sudo service spm-monitor restart
and restart any Java process which was using javaagent/in-process version of SPM monitor.
Few notes to keep in mind:
A: Yes, starting with 1.20.6 version of SPM client you can make SPM monitor reduce the number of messages it logs every minute (otherwise it logs detailed info about its monitoring lifecycle). To do that, change properties files of your SPM applications. You can find those files with:
ls /opt/spm/spm-monitor/conf/spm-monitor-config-*.properties |
You can adjust one or more of them, depending on which application's monitor log output you want to reduce. At the bottom of those files add the following line:
SPM_MONITOR_LOGGING_LEVEL=reduced |
After you have made the changes, restart your SPM monitor – if you are using standalone variant, run: sudo service spm-monitor restart , otherwise restart your application/java process.
SPM monitor by default collects metrics every 10 seconds. To reduce this frequency to 30 seconds, for example, simply add the following line to your SPM monitor properties files located in /opt/spm/spm-monitor/conf :
SPM_MONITOR_COLLECT_INTERVAL=30000 |
The value is expressed in milliseconds. If you are adjusting it, we recommend setting it to 30000. With bigger values it is possible some 1-minute intervals would be displayed without the data in the UI.
After you make this change, make sure SPM monitor is restarted (if using in-process monitor, restart the monitored services; if using standalone monitor, just run sudo service spm-monitor restart).
By default, each standalone SPM monitor process is started with "-Xmx384m" setting. This means that its JVM heap will use 384 MB at most. In many cases SPM monitor doesn't actually need or use that much memory. If you want to be absolutely sure about it, simply lower this number in /opt/spm/spm-monitor/bin/spm-monitor-starter.sh, with the following variable (around line 63):
JAVA_OPTIONS="$JAVA_OPTIONS -Xmx384m -Xms128m -Xss256k" |
You can change "-Xmx" part to "-Xmx192m" for example and see how it goes (check if SPM monitor is still working over the next few hours/days and is still not using much CPU).
We don't recommend changing this setting if you are monitoring Elasticsearch or Solr clusters with a high number of indices or shards. In those cases SPM monitor has to parse and gather large amounts of metrics data returned by Elasticsearch or Solr. You can contact us in chat or via email (spm-support@sematext.com) if you'd like to get more info and help around making this adjustment.
A: Yes. There are really 2 different scenarios here:
1) If each of those applications should be monitored under a different SPM application (e.g., you could have Solr running on your server along with some Java app and you want to monitor both - Solr would be monitored with SPM application of Solr or SolrCloud type, while the Java app would be monitored with SPM application of JVM type), just complete all installation steps from http://apps.sematext.com/spm-reports/client.do for each of them separately.
2) If you want them monitored under the same SPM application (e.g., you have 3 Solr instances running on a server), you must use different JVM name for each of them. To do this, "1. Package installation" step on http://apps.sematext.com/spm-reports/client.do should be run only once on this machine, while "2. Client configuration setup" step should be run once for each of the 3 Solr instances. When running script /opt/spm/bin/spm-client-setup-conf.sh in step "2. Client configuration setup", you should add jvmname parameter (and value) at the end of parameter list, like this:
sudo bash /opt/spm/bin/spm-client-setup-conf.sh 11111111-1111-1111-1111-111111111111 solr javaagent jvmname:solr1 |
In this example, we are setting up things for 3 separate Solr processes, monitored under JVM names: solr1, solr2 and solr3 (you choose any names), so this is adjusted command for solr1 instance.
In the remaining sub-steps of "2. Client configuration setup", replace word "default" with the jvmname value you just used.
"2. Client configuration setup" step will have to be repeated N times, once for each monitored application (in our example 3 times with 3 different jvmname values).
Note: By using this kind of setup, you will be able to see JVM stats of all 3 processes separately (JVM name filter is used to do the filtering). When it comes to other, non-JVM stats, they will be aggregated into single value (for instance, request rate chart will show sum of request rate value of these 3 Solr instances). If you want to see even non-JVM stats separately, you will have to create 3 separate SPM Solr applications (one for each Solr instance running on this machine).
A: SPM client installers currently exist only for Linux, however there is still a way to monitor your service. If you are OK with installing SPM client on separate linux box, and pointing it (more about that further below) to your service (which should be monitored) running on Windows or Mac, you can use SPM to monitor all non-OS related metrics. That means you will not be able to see CPU or system Memory metrics, but metrics specific to your process will be displayed (for example, in case of Solr, you will see all search, index, cache metrics along with all JVM metrics like pool memory, GC stats, JVM threads etc; as another example, in case of MySQL you will see all metrics related to connections, users, queries, handlers, commands, MyISAM, InnoDB, MySQL traffic, etc) .
When monitoring Solr, Elasticsearch, HBase, Hadoop and other Java-based services, you will have an option to choose between using In-process (javaagent) or Standalone monitor. The workaround described here requires the use of standalone monitor variant. Here's what you'd need to do to see your metrics in SPM:
-Dspm.remote.jmx.url parameter used in monitor properties. You will know where to adjust it if you follow standard instructions for Standalone monitor. While this parameter will usually have a value like -Dspm.remote.jmx.url=localhost:3000localhostlocalhostIn case you want to monitor multiple machines belonging to the same cluster in this way, you can still use SPM installed on a single Linux helper box. Just do this:
A: Standalone SPM monitor runs as a separate process, while Embedded monitor runs embedded in the Java/JVM process. Thus, if you are monitoring a non-Java application, Standalone monitor is the only option. Standalone monitor is a bit more complex to set up when one uses it to monitor Java applications because it typically requires one to enable out-of-process JMX access, as described on Standalone SPM monitor page. With Embedded monitor this is not needed, but one needs to add the SPM agent to the Java command-line and restart the process of the monitored application. When running Standalone monitor one can update the SPM monitor without restarting the Java process being monitored, while a restart is needed when Embedded SPM monitor is being used. To be able to trace transactions or database operations you need to use the Embedded SPM monitor.
A: Yes, see Transaction Tracing.
A: Yes. Starting with version 1.22.25, SPM client provides two scripts that can be used to move SPM client files/directories to another location:
1) Soft move script - Moves all SPM files/directories to a new location, but symlinks /opt/spm to the new location. Use this script if you are OK with having /opt/spm symlinked. This script is recommended for most situations since it keeps your SPM client installation completely in line with standard setup (all standard SPM client commands and arguments are still valid).
It accepts 1 parameter: new directory where SPM client should be moved to (if such directory doesn't exist, it will be created)
sudo bash /opt/spm/bin/move-spm-home-dir-soft.sh /mnt/some_dir |
And that is it.
2) Full move script - Moves all SPM files/directories to a new location without leaving any SPM artifacts in /opt directory. Please note that using this script will make management of SPM client a bit harder (for example, there will be some required actions before running SPM client upgrade; also, if you are using in-process (javaagent) type of monitor you will need to adjust some paths in java arguments - more about that below).
It accepts 2 parameters: the current location (by default /opt/spm), and the new location (if such directory doesn't exist, it will be created). It can be run as:
sudo bash /opt/spm/bin/move-spm-home-dir.sh /opt/spm /mnt/some_other_dir/spm |
If you are using in-process (javaagent) versions of SPM monitor to monitor Java-based applications, please adjust agent path(s) you use when starting application(s) you monitor with the SPM agent and make sure to use new location where old location was used before. Also add the following argument to the monitored application's Java process (you can add it right before -javaagent part; adjust the value to match directory you used):
-Dspm.home=/mnt/some_other_dir/spm |
Note: When doing SPM client update on systems where SPM client was moved to different directory using "2) Full move script", you will first have to move SPM back to original /opt/spm directory:
sudo bash /opt/spm/bin/move-spm-home-dir.sh /mnt/some_other_dir/spm /opt/spm |
and then proceed with regular update. After update is done, you can again move SPM client to location which suits you.
A: Yes, see SPM API Reference.
A: Yes, you can use the following command for that (it accepts only one parameter, token of SPM application you want to uninstall):
sudo bash /opt/spm/bin/spm-remove-application.sh 11111111-1111-1111-1111-111111111111 |
A: There are two options: Account Sharing or App Sharing. With Account Sharing, you invite others to your whole account, so they get access to all your applications, dashboards, etc.,. They can also create new apps under your account and invite other users. Depending on the role you assign to invitees, they may be able to administer your apps, dashboards, users or even billing info (change app plan, assign credit card, etc). Account Sharing is very convenient because as soon as a new app (SPM or Logsene or ...) is added to your account or new dashboard is created, all users added to your account get access to it. Of course, the level of access depends on the role you initially assigned to each person.
Unlike Account Sharing, App Sharing is restricted only to a particular app. Nothing besides the shared app is accessible to the invited user (for example, dashboards are at the account level can can thus be shared only through Account Sharing). This option is useful if you want to be very restrictive about which apps can be seen by others.
Account Sharing and App Sharing is not exclusive. You can use both of these two sharing types at the same time. You could Share Account with some users, and use App Sharing to share specific apps with other users.
To Share Account with other users, go to https://apps.sematext.com/users-web/account.do#account-invite
To Share App, go to https://apps.sematext.com/users-web/services.do and click on Settings button for the app you want to share (in modal window which will be opened, select the Manage Users tab).
A: There are 3 common roles available when Sharing Account and Sharing App (OWNER, ADMIN, USER), and one role which is specific only to Account Sharing (BILLING_ADMIN).
Each account has one OWNER (if you created some account, you are its OWNER). Each app also has one OWNER (The OWNER of an app is OWNER of account under which some app was created. If you create an app under your account, you are the OWNER of that app. If some user with whom you've shared your account creates a new app under your account, you are again the OWNER of that app. However, if that user creates a new app under his own account, he will be its OWNER).
Each account and app can have 0 or more ADMINS and USERS. If you added some user as ADMIN to your account, he also automatically gets the ADMIN role for all your apps (account role is transitive to app role).
ADMIN users can modify everything under your account/app except billing related info. They can: create/delete/update all dashboards/alerts/subscriptions/users... Users with USER role have read rights on everything except billing info (they can view all reports, dashboards, alerts...). They can even create/edit their own alerts and subscriptions on apps from shared account (but can't edit other user's alerts/subscriptions, only ADMINs can do that). If they were added to an Account (not to an App), they can also create their own dashboards and add other USERs to your account.
There is a special role available when Sharing Account - BILLING_ADMIN. This role has all rights as the standard ADMIN, but can also access/edit billing-related info. The only thing this role cannot do is change password of your account.
A: When you don't have a credit card that should be used for charging, but some other person has it, you should invite this person and give them the BILLING_ADMIN role. Similarly, if you created an account and defined a credit card, but now want somebody else to take care of all billing related activity (assigning plans and credit cards to various apps), you'd give them the BILLING_ADMIN role.
A: Typically you might have one person create an account via https://apps.sematext.com/users-web/register.do. This account might be considered a "parent" account for your whole organization.
Since the person who created the account would be its OWNER, this person is typically (but not necessarily) a team leader or manager, or somebody whose responsibility is to oversee servers/operations, typically in production. This person might then choose to share his/her whole Account with every other person from the team/organization to allow others to easily access all apps created under that account.
Some of the invited users might be given the ADMIN role, which gives them read and write (and invite) rights. Other invitees might get the USER role, which gives mostly just read rights (plus ability to create/edit their own dashboards/alerts/subscriptions which are available to everyone under the shared account). In some cases, account OWNER will not be able to handle billing related info and will want to invite 1 or more BILLING_ADMINs who will be able to define/edit/delete credit cards and choose plans to be used for apps under your account.
A: Yes, see the Install and Configure playbooks, with examples.
A: Yes, see the Install and Configure module, with examples.
A: Yes, see SPM client Chef Recipe example.
A: Yes. Simply add or edit the SPM_MONITOR_LOGGING_LEVEL property in any of the /opt/spm/spm-monitor/conf/spm-monitor\*.properties files and restart the agent (or the process the agent is attached to). Available levels are: FATAL, ERROR, WARN, INFO, DEBUG, TRACE
A: Yes. If you are installing the RPM, add this to /etc/yum.conf:
proxy=http or https://proxy-host-here:port proxy_username=optional_proxy_username proxy_password=optional_proxy_password |
If you are using apt-get, set the http_proxy environmental variable:
export http_proxy=http://username:password@yourproxyaddress:proxyport |
spm_sender_proxy_host= spm_sender_proxy_port= spm_sender_proxy_user_name= spm_sender_proxy_password= |
A: There can be multiple reasons for this, most likely:
you are missing the ca-certificates package. Use one of the following commands to install it:
sudo apt-get install ca-certificates sudo yum install ca-certificates |
If none of the above eliminates the problem for you try adding a flag to avoid certificate checking. In case the command with wget is failing in your case, add "--no-check-certificate" as wget argument. If command with curl is failing, add "-k" flag.
A: In case you are having issues with SPM, you can create diagnostics package on affected machines where SPM client was installed by running:
sudo bash /opt/spm/bin/spm-client-diagnostics.sh |
The resulting package will contain all relevant info needed for our investigation. You can send it, along with short description of your problem, to spm-support@sematext.com or contact us in chat.
A: Make sure you have followed all steps listed on installation instructions page. Package installation steps should be done first, followed by Client configuration setup. If you have done that and you still don't see application metrics, run sudo bash /opt/spm/bin/spm-client-diagnostics.sh to generate diagnostics package and send it to spm-support@sematext.com with description of your problem.
A: If other Solr/ES charts are showing the data, it is most likely that there were no requests sent to your Solr/ES in the time range you are looking at. Try sending some queries and see if request rate/latency charts will show them. If they don't, please send us an email to spm-support@sematext.com or contact us in chat.
sudo service spm-monitor restart
and restart any other javaagent (in-process) based SPM Monitors by restarting your server which is being monitored.
Make sure user spmmon can have more than 1024 files open:
sudo vim /etc/security/limits.conf spmmon - nofile 32000 sudo vim /etc/pam.d/su session required pam_limits.so |
Restart SPM Monitor after the above changes.
sudo service spm-monitor restart |
and restart any process which is using javaagent/in-process version of SPM monitor.
A: Yes. Since version 1.22.0, SPM client by default uses HTTPS to send metrics data to Sematext servers. If you prefer to use HTTP instead (for example, if you are running SPM on premises or if you don't need metric data to be encrypted when being sent to SPM over the Internet), you can adjust that in /opt/spm/properties/spm-sender.properties by changing protocol to http in property:
spm_sender_receiver_url=https://spm-receiver.sematext.com/receiver/v1 |
A: You should probably enable JMX in your Solr. Add or uncomment the <jmx /> directive in solrconfig.xml and restart Solr. See http://wiki.apache.org/solr/SolrJmx for more info.
A: Most likely you are using standalone variant of Solr monitor. In that case, SPM monitor can't collect metrics which are available only when running in-process. If so, switch to in-process (javaagent) version of SPM monitor.
http.host: "127.0.0.1" |
SPM_MONITOR_ES_NODE_BASICAUTH_USERNAME=yourUsername SPM_MONITOR_ES_NODE_BASICAUTH_PASSWORD=yourPassword |
Restart your SPM monitor after this change (either with sudo service spm-monitor restart in case of standalone monitor or by restarting Elasticsearch node if you are using in-process javaagent).
A: No, one Application is enough. Think of an SPM "Application" as a "HBase Cluster". Thus, to monitor N HBase servers that belong to the same cluster you would create just a single SPM Application and use its Token in SPM configuration file on all HBase servers that are a part of this cluster.
A: There could be 2 possible reasons:
A: Kafka had great metrics in 0.7x versions and then in pre-0.8.2 the metrics had a lot of issues. In short, the MBeans Kafka exposed via JMX were named in a way that made them very difficult/impossible to parse systematically. We worked with the Kafka developers to fix that in Kafka 0.8.2 (see https://issues.apache.org/jira/browse/KAFKA-1481). To make your Kafka Producers, Consumers, and Brokers properly monitorable, upgrade to 0.8.2.
A: SPM let's one configure arbitrary Webhooks to call with Alert event information when Alert events are triggered. The details for HipChat integration are described here.
A: Threshold-based alerts are classic alerts where you choose a metric and a numeric value (a threshold) that, when reached or crossed, triggers an alert.
A: Anomaly Detection uses a number of statistical algorithms to determine if a metric has become anomalous, meaning that its recent values have become significantly different from the "base" – the normal/typical values of that metric. An example of an anomaly is a sudden spike or a sudden dip in a metric value. SPM can trigger alerts when such anomalies are detected.
A: Heartbeat Alerts are extremely useful for keeping an eye on your applications. You create a single Heartbeat Alert for each SPM App. From then on, SPM will watch all instances of your application that are a part of that SPM App. Should SPM not hear from any one of your application's instances for more than N minutes, it will alert you. N can be as low as 2 minutes and you choose it yourself when you create a Heartbeat Alert.
A: If you have previously installed the SPM client package (RPM, Deb, etc.) as described on https://apps.sematext.com/spm-reports/client.do simply upgrade via apt-get (Debian, Ubuntu, etc.), or yum (RedHat, CentOS, etc.), or zypper (SuSE).
Debian/Ubuntu:
wget -O - https://pub-repo.sematext.com/ubuntu/sematext.gpg.key | sudo apt-key add - # NOTE: this will update the sematext gpg key sudo apt-get update && sudo apt-get install spm-client # NOTE: this does not update the whole server, just spm-client |
RedHat/CentOS/...
sudo wget https://pub-repo.sematext.com/centos/sematext.repo -O /etc/yum.repos.d/sematext.repo # NOTE: this will update sematext repo file sudo yum clean all && sudo yum update spm-client # NOTE: this does not update the whole server, just spm-client |
SuSE:
sudo zypper up spm-client |
After that is done, also do:
OR
sudo service spm-monitor restart |
If you used bash script based installer, then just run the installation command again ("curl -ko installer.sh ...." or "wget --no-check-certificate -O installer.sh ..."). There is no need to go through "Client configuration setup" steps from https://apps.sematext.com/spm-reports/client.do since the existing configuration will be preserved.
After that is done, next step is the same as with apt-get/yum/zipper upgrade - you should restart monitored server (if using in-process/javaagent monitor) or standalone SPM monitor.
Note: In case of Memcached, Apache and plain Nginx - after completing upgrade steps described above, you must also run commands described in Step 2 - Client Configuration Setup from https://apps.sematext.com/spm-reports/client.do
Note: If you moved SPM client from /opt/spm to different directory, you will first have to move SPM back to original /opt/spm directory:
sudo bash /opt/spm/bin/move-spm-home-dir.sh /mnt/some_other_dir/spm /opt/spm |
and then proceed with regular update. After update is done, you can again move SPM client to location which suits you.
A: On servers where you want to uninstall the client do the following:
sudo apt-get purge spm-client OR sudo yum remove spm-clientsudo rm -R /opt/spmNote: in case you used installer described on "Other" tab on http://apps.sematext.com/spm-reports/client.do , instead of commands from step 1 run: sudo bash /opt/spm/bin/spm-client-uninstall.sh . After that proceed with steps 2 and 3 described above.
A: SPM agents are sending metrics and data used for filtering those metrics, such as hostnames (which can be obfuscated). To see what exactly is being sent you can use tcpdump or a similar tool to sniff the traffic. SPM agents ship data via HTTPS, but can also ship it via HTTP. Java-based agents let you change the protocol in appropriate files under /opt/spm/spm-sender/conf/ directory, while Node.js-based agents let you change it via the SPM_RECEIVER_URL environmental variable.
A: Usage is metered hourly per-server-per-app. For example:
A: This would be billed like just 1 server.
A: We accept all major credit cards - Visa, MasterCard, American Express, JCB, Discover, and Diners Club. We can also invoice you if you want to pay via ACH or bank wires.
A: Yes, we offer a pre-payment option through invoicing. When you select this option simply email us and let us know how much you want to pre-pay. If you want that credit to cover some period of time you'll want to consider how many apps/servers/containers you need to monitor, whether they are running 24/7, and which plan(s) you'd like. We'll invoice you and, once we receive your payment, we'll enter this amount as credit towards your Sematext account. This amount will then be burned down, based on your usage, on a monthly basis. We'll notify you before your balance gets too low, so that we can repeat the invoicing process before your credit runs out.
A: We bill on a monthly basis and send an email to notify you of the amount.
A: Yes, when you select your plan and payment method you will also be able to enter an alternative billing email address. Also, search this FAQ for information about BILLING_ADMIN role.
A: There is no commitment and no contract. When/if you want to stop using SPM you simply stop sending us your metrics and/or switch to the Free plan.
A: Yes, just log in and look under Account > Billing > Invoices. If you don't see invoices there then you likely need to switch to a different account. To do that look for a pull-down menu at the top-right of the UI.