[siddhant]

Hi,

 

MONyog uses the RDS REST API to fetch the log file’s content. The API call requires the access key as well as the secret key as the mandatory parameter. API call based on roles is currently not supported by Amazon. You can ask your admin to create a user and generate the key pair. Also please make sure the user has the required permission to be able to access the log files.

[siddhant]

Hi,

 

The query will appear in Performance Schema database only when it has finished execution. So the user won’t be able to kill the query while it is running like for sniffer in processlist mode. We’ll consider your request for adding the notification for long running query for sniffer in Performance Schema mode.

[siddhant]

You can enable the alert for locked query in the Monitor Long Running Query option of Processlist Sniffer in MONyog. It would alert you whenever a query takes more than a specified time and the state of which is locked. To configure this please goto Edit server > Advanced settings > Sniffer > Enable sniffing? = Yes > Sniffer mode = Processlist > Monitor Long Running Query = Yes > Long running query time = (according to your requirement) > Monitor only locked queries = Check > Save all.

 

This would send you an alert in case the state of a query is locked and it exceeds the given time.

[siddhant]

Hi,

 

The HTML file that you sent us is not rendering properly. Please send us the screenshot of the issue that you are facing to [email protected].

[siddhant]

Hi,

 

This particular error is due to the insufficient privileges for the MySQL user you are using to connect from MONyog. Please try granting the INSERT privilege to the MySQL user used in MONyog.

[siddhant]

Hi,

 

It is highly likely that some other service must be using the port 80 on your system like a web server for example. Please make sure no service is running on that port. However, with many of our customers we have seen MONyog being configured to run behind a proxy, so the requests from port 80 can be forwarded to MONyog default port listening on port 5555. You can consider this option of configuring MONyog with a web server like apache, nginx. For more details on this please refer this step by step FAQs on how to do it:

 

http://monyogkb.webyog.com/article/145-faq#C12 

http://monyogkb.webyog.com/article/145-faq#C13

[siddhant]

Hi,

 

You didn’t receive the alert because the alert-able value in the notification settings must have been set to a greater value than one. This value specifies the number of consecutive times for MONyog to encounter the same problem before sending the mail alert. In simple words, if set to 5 then MONyog needs to encounter the same problem for 5 consecutive times(or 5 consecutive data collections) before sending the mail alert. For example if set to 5 and the data collection interval in 5 minutes then MONyog will have to face the issue for 5*5 = 25 minutes before sending the alert. But setting it to 1 would ensure that the mail alert is fired the first time it encounters the problem. To do this click on edit server > Notification settings > Send notification when alert-able = 1.

 

Regarding the issue that you faced with MONyog unable to collect data for the next two hours, please write back to us at [email protected] with the following details:

 

1). Have you restarted or edited the server so as to resume the data collection or it resumed on it’s own?

 

2). Please send us the MONyog.log file. Depending on the OS and the mode of installation it can be found in one of the following location:

 

Linux

tar: /MONyog/MONyog.log

rpm: /usr/local/MONyog/MONyog.log

 

Windows

exe: ProgramDataWebyogMONyogMONyog.log

 

3). Also, send us the mysql.data file for the server in question. To know the directory associated with that particular server, hover the mouse pointer over the server name in the left panel of MONyog and note the displayed directory number(something like 0001). Now head over to the MONyog folder described above and navigate to /data//mysql.data

[siddhant]

Hi,

 

Please write back to us at [email protected] . Attach the MONyog.log file. Depending on the OS and mode of installation it can be found in one of the following location:

 

Linux:

RPM: /usr/local/MONyog/MONyog.log

TAR: /MONyog/MONyog.log

 

Windows:

ProgramDataWebyogMONyogMONyog.log

[siddhant]

Hi,

 

We are unable to reproduce the issue i.e. the chart values are consistent on both windows and linux platform browser’s. Can you please write back to us at [email protected] and send us the mysql.data file of any of the server showing problematic behavior.

[siddhant]

Hi,

 

Can you please tell us on which OS have you installed MONyog. Also, send us the mysql.data file of the problematic server by writing back to us on [email protected]. To identify the directory associated with the server, hover the mouser over the server name and you’ll notice the directory number like 0001. Now depending on the OS and the mode of installation, navigate to the data directory inside MONyog directory and send us the mysql.data file inside the directory number corresponding to the server.

 

Windows:

ProgramDataWebyogMONyogdata

 

Linux:

 

tar: /MONyog/data/

rpm: /usr/local/MONyog/data/

[siddhant]

Hi,

 

You can follow these steps given in our documentation for adding a custom advisor. You need to enable this advisor using certain MySQL parameters, which I’ll assume you meant the global status and global variables. You can make use of the MOM (MONyog Object Model) to access these variables and create a custom counter. For example if you want to access the global variable log_warnings and global status Aborted_connects, you can do it using MOM in the following way:

 

MONyog.MySQL.GlobalVariables.log_warnings

MONyog.MySQL.GlobalStatus.Aborted_connects

 

You can use this in the Value field inside the JavaScript function. To know more about on how to Add a new monitor/advisor in MONyog please refer to these links:

 

http://monyogkb.webyog.com/article/103-adding-new-monitors 

http://monyogkb.webyog.com/article/108-monyog-object-model

 

If you still face any issue, please write back to us.

[siddhant]

Hi,

 

MONyog makes use of the performance_schema database of the MySQL for the sniffer functionality only i.e. performance_schema needs to be enabled if you have configured the sniffer in MONyog using the performance_schema. Sniffer can be enabled in three different modes.

 

1). Processlist mode

2). Performance Schema mode

3). MySQL Proxy mode

 

I’ll elaborate on the first two for you to choose from. 

 

Performance Schema based sniffer makes use of the performance_schema database of the MySQL server. Performance_schema database if enabled, logs in each and every query(even the short lived one’s) in one of it’s table. MONyog queries the performance_schema and retrieve the queries therefore allowing MONyog to log in even the short lived queries. A disadvantage of it is that it causes a bit of an overhead on the server. For performance schema based sniffer the default sniffing time interval is 1 minute. Please note that performance schema was introduced as of MySQL version 5.6.14.

 

Processlist based sniffer on the other hand fires the query SHOW FULL PROCESSLIST to the MySQL server to retrieve the queries running on the server at that instant. Please note that in this method short lived queries may get missed, as it returns the queries running at that very instant only. Although, it do not create much of an overhead. The choice solely depends on your monitoring goals. For processlist based sniffer the default time is 1 second.

 

Apart from the sniffer in query analyzer(that too if you enable it with performance schema mode), performance schema is not used anywhere else in MONyog.

[siddhant]

Can you please share with us the MONyog.log file. Upload the file on Dropbox and share the link with us at [email protected].

[siddhant]

Hi,

 

We are checking the issue an will get back to you shortly.

[siddhant]

Hi,

 

If MONyog fails to send a notification alert it logs this error in the MONyog.log file. An example error which occurs due to incorrect credentials looks something like this:

smtpcallback.cpp(158) ErrCode:1 ErrMsg:Retrying PLAIN authentication after 535 5.7.8 http://support.google.com/mail/bin/answer.py?answer=14257 fp13sm181179



smtpcallback.cpp(158) ErrCode:2 ErrMsg:Can not authenticate to SMTP server: 535 5.7.8 http://support.google.com/mail/bin/answer.py?answer=14257 fp13sm181179

Please see if you get errors like this logged in your MONyog.log file. If this has anything to do with an error with your SMTP server, the error message can be found here.

 

Also. please check if you understand the concept of alert-able and have it configured to send alert notification immediately. Please follow these steps:

 

1. Click on the button in front of the server on the left panel in MONyog and select Edit server.
2. On the edit server page click on the Notification settings tab.
3. Check if the Send notifications over mail(SMTP)? is set to Yes. Also check if your mail settings are properly configured.
4. Now in the Send notification when alert-able set the value to 1.(default if 5)

The value in this field specifies the number of consecutive times for MONyog to encounter the same problem before sending the mail alert. In simple words, if set to 5 then MONyog needs to encounter the same problem for 5 consecutive times(or 5 consecutive data collections) before sending the mail alert. But setting it to 1 would ensure that the mail alert is fired the first time it encounters the problem. Please refer to the attached screenshot.

 

 

 

If this still doesn’t solve the issue, please share with us the events.data file for the problematic server in the MONyog’s data directory. Upload it to Dropbox and share with us the link for the same by writing us back to [email protected]

[Author]

Posts