I think I have a solution:
In the guests' XML files, I set a target device name
so they will always use a known device (Instead of
getting an aribtrary vnet* device).
Next, using snmp on the host, I can get the interface stats
for that device and use cacti to graph it.
Thanks to everyone for
Couple of diff ways to go about this.
I use Cacti and monitor throughput via SNMP for the dom0.
I also enable SNMP on my switch and monitor throughput of individual
ports.
However if you want granularity like monitoring at the network layer
(IP or layer 3), then you can look at the netflow
On Fri, Oct 23, 2009 at 12:07 PM, Neil Aggarwal wrote:
> Matt:
>
> > depending on what your using for virtualization, you might be able to
> pull
> all
> > of those stats with snmp on the host.
>
> I am using KVM on CentOS 5.4
>
> Let me know if you think it is possible to gather everything
> I ne
> I took a look and I think it requires software running on
> each guest to report the data back to the centralized
> system. Is that correct?
Yes
> If so, I am looking for a solution that does not require
> any software on the guest machines.
Oh well, it is not for you then. But it is a prett
- "Les Mikesell" escreveu:
> Neil Aggarwal wrote:
> > Matt:
> >
> >> why not just use your current cacti setup and
> >> enable snmp on each of the hosts? That seems like
> >> the simplest and cheapest approach.
> >
> > As I understand it, I would actually have to
> > enable snmp on eac
Neil Aggarwal wrote:
> Matt:
>
>> why not just use your current cacti setup and
>> enable snmp on each of the hosts? That seems like
>> the simplest and cheapest approach.
>
> As I understand it, I would actually have to
> enable snmp on each of the guests, not the hosts.
>
> Am I wrong?
>
Matt:
> depending on what your using for virtualization, you might be able to pull
all
> of those stats with snmp on the host.
I am using KVM on CentOS 5.4
Let me know if you think it is possible to gather everything
I need at the host without requirining anything from the guests.
Thanks,
On Fri, Oct 23, 2009 at 11:58 AM, Neil Aggarwal wrote:
> Matt:
>
> > why not just use your current cacti setup and
> > enable snmp on each of the hosts? That seems like
> > the simplest and cheapest approach.
>
> As I understand it, I would actually have to
> enable snmp on each of the guests, no
Matt:
> why not just use your current cacti setup and
> enable snmp on each of the hosts? That seems like
> the simplest and cheapest approach.
As I understand it, I would actually have to
enable snmp on each of the guests, not the hosts.
Am I wrong?
Thanks,
Neil
--
Neil Aggarwal,
On Fri, Oct 23, 2009 at 11:44 AM, Neil Aggarwal wrote:
> > Alternately you could use something like Munin to monitor on
> > the box itself.
>
> I took a look and I think it requires software running on
> each guest to report the data back to the centralized
> system. Is that correct?
>
> If so, I
> Alternately you could use something like Munin to monitor on
> the box itself.
I took a look and I think it requires software running on
each guest to report the data back to the centralized
system. Is that correct?
If so, I am looking for a solution that does not require
any software on the
> Can one setup a Linux server to offer sflow? If the Linux host can run
> sflow, then it's easy to capture the bandwidth usage on the host?
That is a good idea. Since we have to have the host OS running,
it might be able to do the collection activities for us.
If anyone has a soution for this,
nate wrote:
> Neil Aggarwal wrote:
>
>> I just need something that gives me a usage graph
>> at daily, weekly, and monthly intervals with a 95%
>> line.
>
> Don't use RRD for billing 95% it will not be accurate
> as RRD averages values over time. I use rtg (not mrtg,
> but rtg) together with SNMP
> Currently, I use Cacti to graph the data coming
> from my switches. Do you know if that will that
> work with any of these switches?
Alternately you could use something like Munin to monitor on the box itself.
--
“Don't eat anything you've ever seen advertised on TV”
- Michael Polla
Neil Aggarwal wrote:
> I just need something that gives me a usage graph
> at daily, weekly, and monthly intervals with a 95%
> line.
Don't use RRD for billing 95% it will not be accurate
as RRD averages values over time. I use rtg (not mrtg,
but rtg) together with SNMP to get accurate 95% readin
> http://www.sflow.org/products/collectors.php
>
> ntop would probably be the main "free" flow based monitor,
> though there are some really really nice commercial
> products.
I just need something that gives me a usage graph
at daily, weekly, and monthly intervals with a 95%
line.
It looks like
On Fri, Oct 23, 2009 at 4:04 PM, nate wrote:
> Neil Aggarwal wrote:
>> Nate:
>>
>> Thanks for the suggestion. I am looking into it
>> now.
>>
>> Currently, I use Cacti to graph the data coming
>> from my switches. Do you know if that will that
>> work with any of these switches?
>
> Cacti will w
Neil Aggarwal wrote:
> Nate:
>
> Thanks for the suggestion. I am looking into it
> now.
>
> Currently, I use Cacti to graph the data coming
> from my switches. Do you know if that will that
> work with any of these switches?
Cacti will work for port based monitoring, it won't work
for flow-based
, October 23, 2009 8:50 AM
> To: centos@centos.org
> Subject: Re: [CentOS] Switch to measure traffic at IP level?
>
> Neil Aggarwal wrote:
> > Hello all:
> >
> > Is there a network switch that will give me traffic
> > stats at an IP address level?
>
Neil Aggarwal wrote:
> Hello all:
>
> Is there a network switch that will give me traffic
> stats at an IP address level?
any of these can:
http://www.sflow.org/products/network.php
Myself I'm biased towards Extreme networks having used them
for almost 10 years now, very easy to use.
nate
___
Hello all:
Is there a network switch that will give me traffic
stats at an IP address level?
Right now, I only get statstics at a port level, but
that does not help since each of my servers run several
virtual machines and I need to measure traffic
per virtual machine.
Thanks,
Neil
--
N
21 matches
Mail list logo
