Oktober 2016 - Seite 83 von 145 - Cloud Computing Köln

We have enhanced the schema of Analytics, the powerful query language of Visual Studio Application Insights. We’ve separated metrics into performanceCounters and customMetrics, and we’ve introduced browserTimings to show page load data from the client side. These changes improve the discoverability of the data, simplifying your queries and exposing new metrics and dimensions of your telemetry.

performanceCounters schema

This schema is the single place where you should look for any performance counter that is reported from your application. Whether the performance counter is automatically collected by Application Insights SDK or you have configured the application to send other performance counters, the data can be found in this schema.

For example, to find out what performance counters are being reported:

To get a chart of available memory over the recent period:

The performanceCounters schema exposes the category, counter name, and instance name of each performance counter. Counter instance names are only applicable to some performance counters, and typically indicate the name of the process to which the count relates. In the telemetry for each application, you’ll see only the counters for that application. Let’s see what counters are available in our sample telemetry:

Like other telemetry, performanceCounters also has a column cloud_RoleInstance that indicates the identity of the host machine on which your app is running. For example, to compare the performance of your app on the different machines:

customMetrics schema

If you are using TrackMetric() to send your own telemetry, you’ll find that in the customMetrics schema. For example:

browserTimings schema

At last we expose client side metrics. Many of you have asked for this and we are happy to support your request.

Set up your app for client-side telemetry in order to see these metrics.

The new schema includes the following metrics: networkDuration, sendDuration, receiveDuration, processingDuration and totalDuration. These metrics indicate the lengths of different stages of the page loading process. (They don’t indicate the length of time your users read a page.)

name can be used to filter by page name, and there are also properties such as client_OS and client_Browser. We also provide you with the performanceBucket property to quickly analyze and group the client side metrics by buckets.

For example, to find out which pages on your site are most popular, and how long they take to load:

Tell us what you think

We hope these changes help you to understand your application’s usage and performance better. The data is there – all you have to do is just query it.

As always, feel free to send us your questions or feedback by using one of the following channels:

Suggest ideas and vote in Application Insights ideas
Join the conversation at the Application Insights Community
Try Application Analytics

Quelle: Azure

18. Oktober 201618. Oktober 2016

da Agency

DocumentDB updates in the Azure Portal: New metrics blade and improved collections management

Recently we released several updates to the #Azure DocumentDB portal experience. We added a new consolidated metrics experience with several new metrics available including new availability, throughput, consistency, and latency metrics which allows you to track how DocumentDB is meeting its SLA's. We also streamlined collection management by surfacing all collection operations and experiences on the left navigation bar, and eliminated excessive horizontal scrolling.

New metrics blade and SLA metrics

Azure DocumentDB is a globally distributed managed NoSQL database as a service that offers 99.99% guarantees for availability, throughput, <10ms read latency and <15ms write latency at 99th percentile, and guarantees 100% consistency. We believe it is important for you to know how the service is performing against these guarantees. We also heard how important it is for you to have all metrics information readily available without browsing through multiple windows. In response to this feedback, we have added several new metrics to reflect service performance vs SLA, as well as introduced a new at-a-glance metrics experience for DocumentDB collections. If you click on the Metrics node under Collections, you will see all metrics DocumentDB provides for each of your collections on a single surface, including:

Actual collection availability vs. SLA
Requests rate grouped by status code
Consumed and provisioned throughput capacity measured in Request Units/second, as well as percentage of requests exceeding capacity
Observed latency in the regions where your collection is located
Percentage of requests that met consistency guarantees
Storage consumed vs. capacity

You can also zoom in and navigate to the standard metrics experience for the individual charts via zoom-in gesture.

Streamlined collections management

DocumentDB stores data in collections, and majority of your time working with DocumentDB is spent working with collections. With this portal change, we bring collections front and center in the portal experience and eliminate the excessive horizontal scrolling you used to encounter when working in the portal.

The overview blade now provides one-click access to collections, as well as "Add Collection" command.
All collection management experiences and tools are now available on the left navigation menu.
With this update, we eliminated the need for horizontal scrolling when working with DocumentDB in Azure portal.

We hope these new features will make your time in the Azure portal more efficient and provide you with the monitoring information that’s most important to you. As always, let us know how we are doing and what improvements you&039;d like to see going forward through Uservoice, StackOverflow azure-documentdb, or Twitter @documentdb.
Quelle: Azure

18. Oktober 201618. Oktober 2016

da Agency

Total Cost of Ownership: AWS TCO vs OpenStack TCO Q&A

The post Total Cost of Ownership: AWS TCO vs OpenStack TCO Q&A appeared first on Mirantis | The Pure Play OpenStack Company.
Last month, Amar Kapadia led a lively discussion about the Total Cost of Ownership of OpenStack clouds versus running infrastructure on Amazon Web Services. Here are some of the questions we got from the audience, along with the answers.
Q: Which AWS cost model do you use? Reserved? As you go?
A: Both. We have a field that can say what % are reserved, and what discount you are getting on reserved instances. For the webinar, we assumed 30% reserved instances at 32% discount. The rest are pay-as-you-go.
Q: How does this comparison look when considering VMware’s newly announced support for OpenStack? Is that OpenStack support with VMware only with regards to supporting OpenStack in a “Hybrid Cloud” model? Please touch on this additional comparison. Thanks.
A: In general, a VMware Integrated OpenStack (VIO) comparison will look very different (and show a much higher cost) because they support only vSphere.
Q: Can Opex be detailed as per the needs of the customer? For example, if he doesn&8217;t want an IT/Ops team and datacenter fees included as the customer would provide their own?
A: Yes, please contact us if you would like to customize the calculator for your needs.
Q: Do you have any data on how Opex changes with the scale of the system?
A: It scales linearly. Most of the Opex costs are variable costs that grow with scale.
Q: What parameters were defined for this comparison, and were the results validated by any third party, or on just user/orgnaisatuon experience?
A: Parameters are in the slide. Since there is so much variability in customers&8217; environments, we don&8217;t think a formal third party validation makes sense. So the validation is really through 5-10 customers.
Q: How realistic is it to estimate IT costs? Size of company, size of deployment, existing IT staff (both firing and hiring), each of these will have an impact on the cost for IT/OPs teams.
A: The calculator assumes a net new IT/OPS team. It&8217;s not linked to the company size, but rather the OpenStack cloud size. We assume a minimum team size of about 3.5 people and linear growth after that as your cloud scales.
Q: Should the Sparing not be adding more into the cost, as you will need more hardware for HA for high availability?
A: Yes, sparing is included.
Q: AWS recommends using 90% utilization, and if you are using 60%, it&8217;s better to downgrade the VM to ensure 90% utilization. In the case of provisioning 2500 vms with autoscaling, this should help.
A: Great point, however, we see a large number of customers who do not do this, or do not even know what percentage of their VMs are underutilized. Some customers even have zombie VMs that are not used at all, but they are still paying for them.
Q: With the hypothesis that all applications can be &8220;containerized&8221;, will the comparison outcomes remain the same?
A: We don&8217;t have this yet, but a private cloud will turn out to have a much better TCO. The reason is that we believe private clouds can run containers on bare-metal while public clouds have to run containers in VMs for security reasons. So a private cloud will be a lot more efficient.
Q: This is interesting. Can you please add replication cost? This is what AWS does free of cost within an availability zone. In the case of OpenStack, we need to take care of replication.
A: I assume you mean for storage. Yes we already include a 3x factor to convert from raw storage to usable storage to factor in replication (3-way).
Q: Just wondering how secure is the solution as you have mentioned for a credit card company? AWS is PCI DSS certified.
A: Yes this solution is PCI certified.
Q: Has this TCO calculator been validated against a real customer workload?
A: Yes, 5-10 customers have validated this calculator.
Q: Do you think that these costs apply to another countries, or this is US based?
A: These calculations are US based. Both AWS and private cloud costs could go up internationally.
Q: Hi, thank you for your time in this webinar. How many servers (computes, controllers, storage servers) are you using, and which model do you use for your calculations ? Thanks.
A: The node count is variable. For this webinar, we assumed 54 compute nodes, 6 controllers, and 1080GB of block storage. We assumed commodity Intel and SuperMicro hardware with 3 year warranty.
Q: Can we compare different models, such as AWS vs VMware private cloud/public cloud with another vendor (not AWS)?
A: These require customizations. Please contact us.
The post Total Cost of Ownership: AWS TCO vs OpenStack TCO Q&038;A appeared first on Mirantis | The Pure Play OpenStack Company.
Quelle: Mirantis