Elastix: Outbound calling issue
-
@scottalanmiller said:
@g.jacobse Why would updates from MS trigger updates? Are they running on HyperV?
In this case, the DC reported there were updates available and a reboot was needed. so, while I have not verified it, all boxes were touched to ensure being up to date and restarted as needed.
-
current GUI
-
Sar:
sar Linux 2.6.18-371.1.2.el5 (pbx.XXX.com) 08/16/2015 12:00:01 AM CPU %user %nice %system %iowait %steal %idle 12:10:01 AM all 0.05 0.00 0.09 1.81 0.00 98.06 12:20:01 AM all 0.04 0.00 0.10 1.12 0.00 98.74 12:30:01 AM all 0.07 0.00 0.09 0.95 0.00 98.89 12:40:01 AM all 0.05 0.00 0.09 1.17 0.00 98.69 12:50:01 AM all 0.04 0.00 0.10 1.64 0.00 98.22 01:00:01 AM all 0.05 0.00 0.09 1.81 0.00 98.05 01:10:01 AM all 0.04 0.00 0.09 1.53 0.00 98.34 01:20:01 AM all 0.04 0.00 0.10 1.05 0.00 98.81 01:30:01 AM all 0.07 0.00 0.10 1.37 0.00 98.46 01:40:01 AM all 0.04 0.00 0.09 1.57 0.00 98.30 01:50:01 AM all 0.04 0.00 0.10 1.35 0.00 98.51 02:00:01 AM all 0.04 0.00 0.09 0.96 0.00 98.91 02:10:01 AM all 0.04 0.00 0.09 1.65 0.00 98.21 02:20:01 AM all 0.04 0.00 0.10 1.35 0.00 98.51 02:30:01 AM all 0.07 0.00 0.09 1.55 0.00 98.29 02:40:01 AM all 0.04 0.00 0.08 1.18 0.00 98.70 02:50:01 AM all 0.04 0.00 0.10 1.18 0.00 98.68 03:00:01 AM all 0.04 0.00 0.08 1.17 0.00 98.71 03:10:01 AM all 0.05 0.00 0.09 1.91 0.00 97.95 03:20:01 AM all 0.04 0.00 0.11 0.91 0.00 98.94 03:30:01 AM all 0.07 0.00 0.10 1.16 0.00 98.67 03:40:01 AM all 0.04 0.00 0.09 1.10 0.00 98.77 03:40:01 AM CPU %user %nice %system %iowait %steal %idle 03:50:01 AM all 0.04 0.00 0.10 1.33 0.00 98.54 04:00:01 AM all 0.04 0.00 0.09 1.23 0.00 98.64 04:10:01 AM all 0.28 0.00 0.18 1.78 0.00 97.76 04:20:01 AM all 0.04 0.00 0.10 1.67 0.00 98.18 04:30:01 AM all 0.07 0.00 0.10 1.33 0.00 98.50 04:40:01 AM all 0.04 0.00 0.09 1.31 0.00 98.57 04:50:01 AM all 0.04 0.00 0.10 1.38 0.00 98.48 05:00:01 AM all 0.04 0.00 0.09 1.34 0.00 98.53 05:10:01 AM all 0.04 0.00 0.09 1.62 0.00 98.24 05:20:01 AM all 0.04 0.00 0.11 1.10 0.00 98.75 05:30:01 AM all 0.06 0.00 0.10 1.22 0.00 98.62 05:40:01 AM all 0.04 0.00 0.09 1.43 0.00 98.44 05:50:01 AM all 0.04 0.00 0.10 1.68 0.00 98.17 06:00:01 AM all 0.04 0.00 0.09 1.34 0.00 98.53 06:10:01 AM all 0.05 0.00 0.09 1.11 0.00 98.75 06:20:01 AM all 0.04 0.00 0.10 0.72 0.00 99.14 06:30:01 AM all 0.07 0.00 0.10 1.04 0.00 98.79 06:40:01 AM all 0.04 0.00 0.09 1.58 0.00 98.30 06:50:01 AM all 0.04 0.00 0.10 1.28 0.00 98.58 07:00:01 AM all 0.03 0.00 0.07 0.75 0.00 99.14 07:10:01 AM all 0.04 0.00 0.07 0.38 0.00 99.51 07:20:01 AM all 0.04 0.00 0.08 0.29 0.00 99.60 07:20:01 AM CPU %user %nice %system %iowait %steal %idle 07:30:01 AM all 0.06 0.00 0.09 0.30 0.00 99.56 07:40:01 AM all 0.04 0.00 0.08 0.27 0.00 99.61 07:50:01 AM all 0.04 0.00 0.09 0.27 0.00 99.61 08:00:01 AM all 0.03 0.00 0.07 0.25 0.00 99.64 08:10:01 AM all 0.04 0.00 0.07 0.34 0.00 99.55 08:20:01 AM all 0.04 0.00 0.08 0.42 0.00 99.46 08:30:01 AM all 0.06 0.00 0.08 0.32 0.00 99.55 08:40:01 AM all 0.03 0.00 0.07 0.36 0.00 99.54 08:50:01 AM all 0.04 0.00 0.08 0.29 0.00 99.59 09:00:01 AM all 0.03 0.00 0.07 0.31 0.00 99.58 09:10:01 AM all 0.04 0.00 0.08 0.39 0.00 99.50 09:20:01 AM all 0.04 0.00 0.09 0.34 0.00 99.53 09:30:01 AM all 0.06 0.00 0.08 0.28 0.00 99.58 09:40:01 AM all 0.03 0.00 0.07 0.30 0.00 99.60 09:50:01 AM all 0.04 0.00 0.08 0.33 0.00 99.55 10:00:01 AM all 0.04 0.00 0.07 0.37 0.00 99.52 10:10:01 AM all 0.04 0.00 0.08 0.37 0.00 99.52 10:20:01 AM all 0.03 0.00 0.08 0.31 0.00 99.58 10:30:01 AM all 0.06 0.00 0.08 0.65 0.00 99.22 10:40:01 AM all 0.03 0.00 0.07 0.37 0.00 99.53 10:50:01 AM all 0.04 0.00 0.08 0.35 0.00 99.53 11:00:01 AM all 0.04 0.00 0.07 0.31 0.00 99.58 11:00:01 AM CPU %user %nice %system %iowait %steal %idle 11:10:01 AM all 0.03 0.00 0.08 0.34 0.00 99.55 11:20:01 AM all 0.04 0.00 0.09 0.29 0.00 99.58 11:30:01 AM all 0.06 0.00 0.08 0.37 0.00 99.48 11:40:01 AM all 0.04 0.00 0.08 0.29 0.00 99.60 11:50:01 AM all 0.04 0.00 0.09 0.35 0.00 99.53 12:00:01 PM all 0.04 0.00 0.08 0.25 0.00 99.64 12:10:01 PM all 0.04 0.00 0.08 0.39 0.00 99.50 12:20:01 PM all 0.03 0.00 0.08 0.30 0.00 99.58 Average: all 0.05 0.00 0.09 0.90 0.00 98.97 -
@g.jacobse said:
@scottalanmiller said:
@g.jacobse Why would updates from MS trigger updates? Are they running on HyperV?
In this case, the DC reported there were updates available and a reboot was needed. so, while I have not verified it, all boxes were touched to ensure being up to date and restarted as needed.
What is the connection between a DC (Windows VM) needing an update have with a PBX? There is some connection here that we aren't being told.
-
Based on your screenshots, there was no reboot. Who told you that they rebooted?
-
@scottalanmiller said:
@g.jacobse said:
@scottalanmiller said:
@g.jacobse Why would updates from MS trigger updates? Are they running on HyperV?
In this case, the DC reported there were updates available and a reboot was needed. so, while I have not verified it, all boxes were touched to ensure being up to date and restarted as needed.
What is the connection between a DC (Windows VM) needing an update have with a PBX? There is some connection here that we aren't being told.
No - DC and the PBX Host are different machines
-
@g.jacobse said:
No - DC and the PBX Host are different machines
I know. So why does anything with the DC mean anything with the PBX?
-
@scottalanmiller said:
Based on your screenshots, there was no reboot. Who told you that they rebooted?
Reboot would have been before 14:00 EDT yesterday
-
@g.jacobse said:
Reboot would have been before 14:00 EDT yesterday
Yes, more than two days ago is the last reboot. It says right on the screen that you showed.
-
uptime 12:28:49 up 2 days, 22:19, 1 user, load average: 0.00, 0.00, 0.00I may have been incorrectly informed as such then. I will have to validate that statement.
-
I think it is safe to stop looking at the FreePBX capacity screen and the SAR reports. There is no reason to believe that there is a capacity issue and the FreePBX screen shows wrong information and should never be used for this type of diagnoses anyway. SAR shows no issues with capacity even when there is a problem. Continuing to look at them is just distracting from diagnosis at this point.
There isn't much to work with, unless the logs show something, the best option is to look at the system at a time during which it has failed.
-
@g.jacobse said:
uptime 12:28:49 up 2 days, 22:19, 1 user, load average: 0.00, 0.00, 0.00I may have been incorrectly informed as such then. I will have to validate that statement.
Well if someone was telling you that it was rebooted because the DC rebooted, there is bad information guaranteed since "because" makes no sense in that case.
-
I have to admit that some assumptions were made on my part. These assumptions are incorrect. the VM host may have been rebooted but that doesn't seem (as shown) that it affected the VM.
This is most likely a case of sitting to close to the screen and not seeing the larger picture of how VMs work.
-
We've been through the /var/log/messages log and there is nothing in there to say that anything was amiss. This doesn't mean that nothing was logged but it does suggest that issues are in Asterisk or the trunk and not within the OS.
-
You should scour the Asterisk log from the time period when the outbound calls failed to see if there is something anomalous that happened around that time.
-
What is the call volume? I've read reports of Vitelity doing some strange things when there is a lot of calling. This seems to be linked to the trunk somehow and the best way to diagnose that is to dig into the Asterisk logs and see if there are any rejection messages related to the trunk.
-
@coliver said:
What is the call volume? I've read reports of Vitelity doing some strange things when there is a lot of calling. This seems to be linked to the trunk somehow and the best way to diagnose that is to dig into the Asterisk logs and see if there are any rejection messages related to the trunk.
Weekend call volume is nil - during the week, I've never checked.
-
@g.jacobse said:
@coliver said:
What is the call volume? I've read reports of Vitelity doing some strange things when there is a lot of calling. This seems to be linked to the trunk somehow and the best way to diagnose that is to dig into the Asterisk logs and see if there are any rejection messages related to the trunk.
Weekend call volume is nil - during the week, I've never checked.
Was there an issue this morning?
-
@coliver said:
@g.jacobse said:
@coliver said:
What is the call volume? I've read reports of Vitelity doing some strange things when there is a lot of calling. This seems to be linked to the trunk somehow and the best way to diagnose that is to dig into the Asterisk logs and see if there are any rejection messages related to the trunk.
Weekend call volume is nil - during the week, I've never checked.
Was there an issue this morning?
Thus far, no comments have been made. I just checked the GUI, only 1 call being shown. CPU usage shows less than 5 and memory usage is below 350.
While the GUI show memory usage jumped from about 180 to over 300 around 12:30am, CPU usage at that time was steady..
No reports from the site as of yet.
-
Any additional problems?
