On the documentation page for Supported logs and Discovered fields, we can see an overview of what fields Cloudwatch might discover. How can I detect what fields my logstream contains using the SDK?
I know such functionality must exists, as you can see a nice little list of your discovered fields when using the Insights dashboard on the AWS Cloudwatch UI:
After posting my question, I looked at the documentation one more time and found the method that I needed: getLogGroupFields.
Related
I've been through Zuora's docs and a number of sites named "sandbox" but I cannot find a reference to a way to simulate errors in a manner like Stripe and others provide. Does such a page exist?
On the introduction page for the 'APIC Test and Monitor tool' one of the listed features is 'Get alerts on your API Health'. However once inside the tool I can't find any reference on how to generate alerts...
Is it already possibble? Or just an idea for the future?
Great question, thank you for asking. You are absolutely right, we are working on shipping notification/alerts as a pluggable ecosystem. We are building a fully featured API and Webhooks, any platform that leverages an API can be used, as well as email and SMS.
Out of the box we will provide the most popular plugins such as the following:
Slack
BigPanda
HipChat
StatusPage.io
JIRA
Twilio
DataDog
New Relic
Elastic
You will also be able to create alert groups, ex. specific tests/monitoring can be mapped to specific groups.
Will update this space when it becomes available. Your feedback is helpful, what is your preferred method to be notified by?
Thanks!
drive.about.get is described by
the revision 20181101 discovery document in which the endpoint for drive:v3.about.get does not include the standard parameters included in the API EXplorer.
V3 is listed as the preferred version.
Given that the fields parameter is required and expects a keyed value from The returned 'about' resource description I expect that this is an erroneous omission from the discovery specification.
Although it is simple enough to work around this, for me it requires additional documentation to explain the requirement.
I note that this is the first Drive endpoint I have explored - I expect that as I continue I will see more missing required parameter specifications. Perhaps this part of the Google Discovery API schema is optional?
My question is - what is the process to help correct this? How frequently are the discovery specs updated and is it up the the user to monitor these changes.
As an additional note for users - you can provide a fields query parameter value of '*' to return all fields. This has also been touched on in Revisions list and get missing information
Any guidance welcome.
Thanks to Mr.Rebot for the link to Google's Issue Tracker which is the most valuable part of my objective to find an appropriate channel to pursue Discovery Specification inconsistencies.
The Google Developer API sites haven't led me there and there are quite a few minor quirks in the API Discovery docs I'd like to pursue.
I'm currently trying to develop a Chrome extension which can receive notifications using GCM. When the extension is first installed, I register it using chrome.gcm.register(['my_sender_id'], function(registration_id) { console.log(registration_id); });.
I would like to send push messages to everyone who has the extension installed. However, the problem is that GCM requires you to specify the registration ID's of everyone you want to send the message to; you can't just send it to everyone who's connected to the sender ID.
While it would be possible to push the registration ID to a database when the extension is installed, and then consult this database each time I want to send a message, this solution seems sub-optimal (also from a security point of view, since the pushing of the registration ID would be done client-side).
However, Google introduced a solution for this a few years ago: topics. It's possible to simply register each device to a 'global' topic (for example) and when you then want to send a message, you only have to specify the 'global' topic as the receiver. However, I can't find how this registration process is done for Chrome extensions. I've looked everywhere, but it seems like Chrome's GCM module doesn't support this yet. Am I correct in this and if so, is there an alternative way to pull this off?
Any help would be greatly appreciated!
If you call chrome.instanceID.getToken and then use the InstanceID API from your server to subscribe to a topic, it seems to work, but then the chrome extension doesn't get messages when you push to that topic, so I'm not sure if Google just needs to enable something on their side to make it work. But this is the closest I could get to it in any case.
firebaser here
Thanks for the great feedback. There is no way at the moment to subscribe to a topic from a browser. We're aware that having such an API would simplify the development model. We'd love to add this to Firebase, but as usual can't make any promises or commitments.
I am evaluating box for enterprise accounts. Within version 1 docs there are Enterprise Commands such as
create_managed_user
edit_managed_user
etc
Is there V2 commands which are the same ?
Will the existing V1 Commands for these methods be deprecated ?
Updating this, since someone recently referred to it, even though this answer is pretty ancient.
Fully updated:
There is about 20% more surface area available for "Administrative use" in the V2 API, than there was in the V1 Box.com API.
Where? /users
POST to create a new one
GET /users to see all the users in the enterprise
PUT /users/ to update a specific user
GET /users/?fields=a,b,c to get specific fields you want to see, including some non default fields like their enterprise-id, their role, some permissions, etc. See the docs for users, and look for the green fields.
Where else? /groups
POST to create a new one
GET to get a list of all groups
GET /groups//memberships to get a list of all the users in a group
What else? as-user headers can let you build applications that automate processes for your users.
Of course to do all these things, you have to be an admin, granted the permissions to do these various different things.
The V2 API has some admin-level APIs, mostly under the /users endpoint (http://developers.box.com/docs/). However, many methods are still being added to the V2 API, and much of the administrative functionality is only available in the V1 API at the moment. The V2 API does not yet have equivalent method's for create_managed_user or edit_managed_user from V1.
We generally recommend that apps use the V2 API as much as possible, and include V1 calls when needed. As we add more methods to the V2 API, it's best to change your v1 calls as soon as you can.